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EXECUTIVE  SUMMARY 


E.l  BACKGROUND 

The  Office  of  the  Secretary  of  Defense  (OSD)  has  directed 
that  a  Survivable  DSCS  Control  System  (SDCS) ,  including  an  SCCE, 
be  developed.  The  SDCS  is  required  to  provide  a  survivable, 
autonomous  minimal  DSCS  III  network  control  capability.  The  SDCS 
will  be  a  transportable  configuration  that  meets  stringent 
environmental  requirements.  The  SCCE's  MODCOMP  Classic  11/75 
computer  will  not  meet  the  environmental  requirements  of  the 
SDCS.  Consequently,  it  will  be  necessary  to  rehost  the  SCCE  to  a 
militarized  computer.  Within  the  DSCSOC,  several  DOCS  subsystems 
use  DEC  VAX  computers.  These  subsystems  will  be  incorporated  into 
the  SDCS,  and  will  require  rehosting  to  a  militarized  computer. 
Applications  on  the  DEC  VAX  computers  will  run  on  the  Norden 
Systems  Inc.  line  of  MIL  VAX  computers  with  minimal  software 
conversion.  Thus,  these  subsystems  will  likely  be  rehosted  to  MIL 
VAX  computers. 

'  Consequently,  in  order  to  improve  the  commonality  of  computer 
equipment  and  simplify  the  logistic  support  of  the  SDCS,  the 
Norden  Systems  Incorporated  line  of  militarized  VAX  computers  is  a 
prime  candidate  for  the  rehosting  of  the  SCCE  in  the  SDCS. 

The  rehosting  of  the  SCCE  to  the  Norden  MIL  VAX  computer  will 
require  software  conversion,  as  well  as  the  use  of  appropriate 
militarized  peripheral  equipment  and  interface  hardware.  Once  the 
software  is  converted  to  the  MIL  VAX  computer,  it  will  also  be 
compatible  with  the  commercial  DEC  VAX  family  of  computers. 

Consequently,  after  the  SDCS  development  has  been  accomplished, 
the  replacement  of  the  MODCOMP  computer  in  the  DSCSOC  with  a  DEC 
VAX  11/780  will  entail  only  minimal  software  conversion,  and  will 
improve  the  commonality  of  the  SCCE  with  the  other  DEC  VAX  based 
subsystems. 
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In  the  DSCSOC,  the  SCCE  must  concurrently  support  two  active 
satellites.  In  addition,  it  must  maintain  a  data  base  for  a 
third,  standby,  satellite,  and  provide  the  capability  for  a  rapid 
switchover  from  an  active  satellite  to  the  standby  satellite.  In 
the  SDCS,  the  SCCE  must  support  only  one  active  satellite  while 
providing  the  capability  for  switchover  to  a  second,  standby 
satellite. 

E.3  STUDY  OBJECTIVES 

This  study  has  three  primary  objectives: 

a.  The  analysis  of  the  MODCOMP  based  SCCE  to  determine  its 
software  and  hardware  characteristics  and  to  estimate  its 
performance. 

b.  The  assessment  of  the  feasibility,  complexity  and  cost  of 
rehosting  the  SCCE  to  a  MIL  VAX  computer  in  the  SDCS. 

c.  The  assessment  of  the  feasibility,  complexity  and  cost  of 
rehosting  the  SCCE  to  a  DEC  VAX  computer,  after  the 
rehosting  to  a  MIL  VAX  computer  is  completed. 

In  conducting  this  study,  CSC  has  attempted  to  provide  information 
and  insights  that  will  support  a  low  risk,  evolutionary  approach 
to  the  proposed  rehosting  efforts. 

E.4  FINDINGS 

The  major  findings  are  summarized  below: 

a.  The  current  SCCE  uses  a  MODCOMP  Classic  11/75  computer, 
with  2  megabytes  (MB)  of  primary  memory  and  3  disk 
units.  It  adequately  supports  2  active  satellites  with 
real  time  and  interactive  processing. 
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b.  The  SCC E  software  consists  of  243K  lines  of  FORTRAN  and 
64K  lines  of  assembler  and  other  machine-unique  code, 
(refer  to  Table  E-l) .  The  FORTRAN  code  is  easily 
converted  to  either  the  MIL  VAX  or  DEC  VAX  computers. 
The  assembler  code  will  have  to  be  rewritten. 


Table  E-l 

SCCE  Software  Summary 


SOFTWARE  ELEMENT 

FORTRAN 

ASSEMBLER 

LINES  OF  CODE 

LINES  OF  CODE 

Applications 

243,000 

36,000 

System 

0 

28,000 

Total  SCCE 

243,000 

64,000 

c.  Some  FORTRAN  routines  on  the  MODCOMP  have  embedded 
(in-line)  assembler  code.  Neither  the  MIL  VAX  nor  DEC 
VAX  computers  permit  the  use  of  embedded  assembler.  This 
assembler  code  will  have  to  be  converted  into  external 
assembler  routines. 

d.  The  SCCE  in  the  SDCS  can  be  hosted  on  a  MIL  VAX  I 
computer  with  4MB  of  primary  memory  and  2  disk  units. 
Militarized  equipment  is  available  to  support  all 
computer  interfaces.  The  MIL  VAX  I  computer  has  slightly 
improved  performance  over  the  MODCOMP  Classic  11/75.  The 
performance  and  rehosting  costs  of  this  system,  in 
support  of  one  satellite,  appear  in  Table  E-2  and  Table 
E-3,  respectively.  Adequate  margins  exist  for  all  key 
parameters. 
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Table  E-2.  MIL  VAX  System  Performance 


COMPUTER 

PROCESSOR  UTILIZATION 

I/O  UTILIZATION 

Avg 

Plybk 

Busy  Min 

Channel 

(Avg. ) 

Disk* 

MODCOMP 

.25 

.48 

.33 

N/C 

.11/. 44 

MIL  VAX  I 

.20 

.38 

.27 

.11 

.12/. 48 

♦Average/Peak 


Conversion  costs  are  estimated  in  Table  E-3 


Table  E-3.  MIL  VAX  Conversion  Costs 
(Fully  Loaded) 


COST  ELEMENT 

COST 

LABOR 

HARDWARE  (One  Site) 

$3,785,000 

833,363 

TOTAL  COST 

$4,618,363 

♦Excludes  Auxiliary  Executive  Routines 
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e.  The  SCCE  in  the  DSCSOC  can  be  rehosted  on  a  DEC  VAX 

11/780  computer  with  6  MB  of  primary  memory  and  3  disk 
units.  Commerical  equipment  is  available  to  support  all 
computer  interfaces.  The  VAX  11/780  has  slightly 
improved  performance  over  the  MODCOMP  Classic  11/75.  The 
performance  and  rehosting  costs  of  this  system  in  support 
of  two  satellites  appear  in  Table  E-4  and  Table  E-5, 
respectively. 


Table  E-4.  DEC  VAX  11/780  System  Performance 


COMPUTER 

PROCESSOR  UTILIZATION 

I/O  UTILIZATION 

Avg 

Plybk 

Busy  Min 

Channel 

(Avg. ) 

Disk* 

MODCOMP 

.50 

.72 

.66 

N/C 

.22/. 55 

VAX  11/780 

.38 

.54 

.50 

.45 

.24/. 60 

*Average/Peak 

Estimated  conversion  costs  are  presented  in  Table  E-5. 


Table  E-5.  DEC  VAX  11/780  Conversion  Costs 

(Fully  Loaded) 


COST  ELEMENT 

COST 

LABOR 

HARDWARE  (One  Site) 

$  736,000 

380,829 

TOTAL  COST 

$1,116,829 
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f.  The  DEC  VAX  11/780  configuration,  under  peak  conditions 
appears  to  have  inadequate  margin  for  disk  utilization. 
Particular  attention  should  be  paid  to  verifying  this 
analytical  result  and/or  to  evaluating  possible 
work-around  approaches  (e.g.,  minor  software  redesign  or 
spreading  of  the  satellite  files  over  two  disks) .  With 
the  satellite  files  spread  over  two  disks,  peak 
utilization  will  drop  to  0.50,  providing  a  comfortable 
margin  of  safety.  This  low  risk  approach  reduces  disk 
utilization,  but  reduces  the  system's  ability  to  overcome 
certain  types  of  equipment  failure. 

E.5  RECOMMENDATIONS 

As  a  means  of  reducing  the  programmatic  risk  associated  with 
the  rehosting  of  the  SCCE,  CSC  makes  the  following  recommendations: 

a.  The  existing  MODCOMP  system  at  GE  should  be  used  as  much 
as  possible  as  a  test  bed.  It  can  be  used  to  verify 
CSC' s  calculated  system  performance  under  peak  loading 
conditions,  particularly  to  evalute  actual  system  margins. 

b.  The  embedded  assembler  code  on  the  MODCOMP  should  be 
replaced  with  externally  called  routines.  This  will 
permit  the  evaluation  of  its  impact  on  performance. 

c.  Disk  activity  under  peak  loads  should  be  measured  using 
the  MODCOMP  system.  If  sufficient  margins  are  not 
present,  then  work-around  approaches  should  be  evaluated. 

E.6  CONCLUSIONS 

The  SCCE  can  be  rehosted  to  a  Norden  Systems  Inc.  militarized 
MIL  VAX  I  computer  system  to  satisfy  the  requirements  for 
satellite  control  in  the  SDCS.  Software  conversion,  which  will  be 
a  large  part  of  the  rehosting  effort,  can  be  accomplished  with 
minimal  risk. 
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Once  the  rehosting  to  the  MIL  VAX  I  is  completed,  the 
subsequent  rehosting  to  the  DEC  VAX  11/780  is  a  low  risk  effort. 
Applications  software  from  the  MIL  VAX  I  system  will  be  directly 
usable  without  conversion;  some  systems  software  will  have  to  be 
rewritten. 
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INTRODUCTION  AND  SCOPE 


This  report  presents  the  results  of  a  study  of  the 
feasibility  of  redesigning  the  DSCS  Satellite  Configuration 
Control  Element  (SCCE)  so  that  it  can  be  fielded  in  a 
transportable  configuration.  The  principal  area  of  redesign 
involves  the  SCCE’s  commercial  grade  MODCOMP  computer  which  is  not 
suitable  for  a  mobile  environment. 

This  analysis  has  been  performed  by  Computer  Sciences 
Corporation  under  contract  DCA100-81-C-0044,  Task  Order  85-2-B  for 
the  Satellite  Systems  Development  Division  (Code  R420)  of  the 
Defense  Communications  Engineering  Center.  The  study  has  taken 
approximately  six  calendar  months. 

The  Office  of  the  Secretary  of  Defense  (OSD)  has  directed 
that  a  Survivable  DSCS  Control  System  (SDCS)  be  developed  by  the 
Army  (USASATCOMA)  with  first  article  delivery  planned  for  FY 
1988.  In  order  to  meet  this  extremely  tight  schedule,  it  is 
planned  to  redesign  and  repackage  existing  network  and  satellite 
control  subsystems  from  the  fixed  DSCS  Operations  Center  (DSCSOC) 
into  the  required  mobile  configuration.  The  highest  risk  area 
that  has  currently  been  identified  in  the  repackaging  strategy  is 
a  proposed  replacement  of  the  large  and  fragile  Modular  Computers, 
Inc.  (MODCOMP)  fixed-plant  computer  system  used  in  the  SCCE  with  a 
ruggedized,  militarized  replacement. 

Included  in  the  DSCSOC  is  the  MODCOMP  based  SCCE,  and  several 
subsystems  using  Digital  Equipment  Corporation  (DEC)  VAX  computers 
(refer  to  Figure  1-1) .  Consequently,  in  order  to  improve  the 
commonality  of  computer  equipment  and  thus  simplify  logistic 
support  of  the  SDCS,  a  common  militarized  computer  is  required. 
Although  several  manufacturers  offer  candidate  ruggedized  systems, 
the  line  of  militarized  VAX  computers  from  Norden  Systems 
Incorporated  appears  to  offer  the  best  choice  for 


1-1 


» 


i 

/  . 


v 


Figure  1-1.  Evolutionary  SCCE  Rehosting 


the  target  computer.  These  MIL  VAX  computers  are  software 
compatible  with  the  DEC  VAX  equipment  and  use  the  DEC  VMS 
operating  system  and  other  DEC  software.  Consequently,  this  study 
has  used  the  MIL  VAX  computers  as  the  target  machine. 

The  rehosting  of  the  SCCE  from  a  MODCOMP  computer  to  a  MIL 
VAX  computer  will  require  changes  in  both  hardware  and  software. 
Hardware  changes  will  be  necessitated  by  differences  in  computer 
characteristics  and  by  the  more  stringent  environment  of  the 
mobile  configuration.  Software  changes  will  be  required  due  to 
some  differences  in  the  FORTRAN  language  processors  and  different 
assemblers  as  well  as  job  control  statements.  This  will  include 
modifications  to  MODCOMP-based  FORTRAN  application  software  in 
order  to  make  it  compatible  with  the  MIL  VAX  FORTRAN  and  the 
rewriting  of  assembly  language  routines.  These  changes  in  the 
SCCE  hardware  and  software  will  make  the  resulting  system 
compatible  with  the  DEC  VAX  family  of  computers.  Thus,  as  a 
secondary  objective,  CSC  has  analyzed  the  feasibility  of  replacing 
the  MODCOMP  in  the  fixed  environment  of  the  DSCSOC  with  a  DEC  VAX 
computer.  This  would  improve  the  commonality  of  equipment  and 
software  as  well  as  logistic  support  of  the  DSCSOC.  In  following 
the  programmatic  path  from  the  present  MODCOMP  implementation  to  a 
MIL  VAX  system  in  the  SDCS,  and  thence  to  a  DEC  VAX  system  in  the 
DSCSOC,  USASATCOMA  has  a  low  risk,  evolutionary  approach  to 
meeting  new  requirements  and  improving  the  supportability  of  the 
SCCE  (Refer  to  Figure  1-1)  . 

In  conducting  this  study,  CSC  has  relied  heavily  on  the 
formal  documentation  of  the  SCCE.  The  documentation  has  included 
specifications,  interface  control  documents,  source  code  listings, 
handbooks,  etc.  A  complete  list  of  such  documents  appears  in 
Table  1-1.  Because  of  their  availability,  CSC  has  primarily  used 
documents  describing  the  Engineering  Development  Model  or  the 
Interim  Production  Model. 
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In  analyzing  the  potential  rehosting  of  the  SCCE  to  a  MIL  VAX 
computer,  certain  critical  parameters  must  be  considered.  These 
are  primarily  related  to  the  adequacy  of  computer  resources,  viz, 
primary  memory,  secondary  memory  (disk),  and  to  the  computer's 
performance,  viz,  processor  rate,  I/O  bus  transfer  rate.  However, 
the  most  important  parameter  is  the  ability  of  the  rehosted  system 
to  meet  the  performance  requirements  of  the  SCCE.  These 
requirements  are  to  perform  the  functionality  of  the  SCCE  within 
the  necessary  response  times.  In  addition,  we  are  concerned  with 
the  portability  of  the  applications  software,  and  the  ability  of 
the  target  system  to  provide  a  "clean",  functionally  correct 
interface  with  the  non-computer  portion  of  the  system. 


1-4 


K 

~f  * 


1  « 


< 


l 


i  • 


L 


Table  1-1.  SCCE  Descriptive  Documentation 


SCCE  Specifications/Interface  Control  Documents  (G.E.) 


Document  Number 


Title 


SVS-9644-I I -A 


SVS-9788 


SVS-10710-I 


CPCI  Specification,  Part  II  Computer 
Program  Development  Specification  TCP, 
Source  Listings 

SAT/PSCCE  Interface  Control  Document 

Prime  Item  Product  Development 
Specification  (IPM  SCCE) 


SVS-107 10-1 1 


Prime  Item  Product  Fabrication 
Specification  (IPM  SCCE) 


SVS-10712 


Hardwre/Sof tware  Interface  Control 
Document  (IPM) 


SVS-10738-I 


SVS-10738-I I 


SVS-107  39- 1 


SVS-10739-I I 


SVS-10766 


SVS-10767 


SVS-10770-I 


Computer  Program  Development 
Specification  TCP  (IPM  SCCE) 

Computer  Program  Product  Specification 
TCP  (IPM  SCCE) 

Computer  Program  Development 
Specification  CCP  (IPM  SCCE) 

Computer  Program  Product  Specification 
CCP  (IPM  SCCE) 

DOSS/PSCCE  Interface  Control  Document 

RFIS/PSCCE  Interface  Control  Document 

CD/CPS  Development  Specification 
( PSCCE) 


SVS-1Q771-I 

SVS-10774-I 


TCS  Development  Specification  (PSCCE) 

ETI/CCTS  Development  Specification 
(PSCCE) 
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Table  1-1.  SCCE  Descriptive  Documentation  (Cont'd) 


SCCE  Specifications/Interface  Control  Documents  (G.E.)  (Cont'd) 


Document  Number 

SCA-2299 

SCF-ICD-115 

SUM-10738 

SUM-10739 

TR-SCCE-401 


Title 

RFIS/IPM  SCCE  Interface  Control  Document 

SCF/SCCE  Interface  Control  Document 

Telemetry  and  Command  Program  User  Manual 

Communication  Configuration  Program  User 
Manual 

Test  Report  for  the  Hardware  Software 
Integration  of  the  IPM  of  the  SCCE  #4 


Table  1-1 

MODCOMP  Manuals 
Document  Number 
210-60050-008 

210-610501-000 

210-804002-E01 

210- 804003-B01 

211- 834001-C02 

213-804005-H01 
213-804007 -H 02 

220-610400-001 

224-321001-001 

224-404009-002 

224-408005-001 

224-410001-001 

224-421002-000 

224-421005-002 


SCCE  Descriptive  Documentation  (Cont'd) 


Title 

Reference  Manual  MAX  II/III/IV  Systems 
Processors  Assemblers 

Reference  Manual  MAX  IV  Input/Output  Model 
8240 

Language  Reference  Manual  MAX  IV  FORTRAN  IV 

Programmer's  Reference  Manual  MAX  III/IV 
Link  Loader 


Programmer's  Reference  Manual  MAX  IV  NASA 
Extended  FORTRAN  78 

System  Guide  MAX  IV  Basic  I/O  System 

System  Guide  MAX  IV  Data  Storage  Device 
Handlers 

MAX  IV  Library 

Concepts  and  Characteristics 

Theory  of  Operation  Classic  II 
Input/Output  Processor 

Theory  of  Operation  Classic  Moving-Head 
Disk  Controller  Model  4176A 

Theory  of  Operation  Classic  Series 
Controller  DMP  Line  Printer 

Theory  of  Operation  Classic  Series 
Console  Controller 

Theory  of  Operation 
Communications  Interfaces 

Theory  of  Operation  Classic  Series 
Asynchronous  Terminal  Controller 
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SCCE  Descriptive  Documentation  (Cont'd) 


Table  1-1. 


MODCOMP  Manuals 


Document  Number 
224-426001-001 


224-427001-001 


Title 


Theory  of  Operation 

Quad  Channel  Interface  Controller  (4804) 
(QCIC) 

Theory  of  Operation  Classic  Series 
Parallel  Interface  Controller 


224-722001-001 


Theory  of  Operation  Classic  II 
Central  Processor  Model  CLII/75 


225-200085-001  Technical  Manual  Electrostatic 

Printer/Plotter  (Models  4216  and  4217) 


225- 200125-001  Data  Terminal/Computer  Link,  Model 

4805-1/Model  4802,  Theory  of  Operation 

226- 722001-004  Computer  Reference  Manual  Classic  Central 

Processor  CLII/75 


Other  Documents 

Norden  Systems  Inc.  MIL  VAX  I  Manuals 

Digital  Equipment  Corporation  VAX  11/780  Manuals 
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2.  BACKGROUND 


2.1  DSCSOC  SCCE  Capability 

2.1.1  General 


The  DSCSOC-based  SCCE  is  a  ground  based  satellite  command  and 
telemetry  processing  system  consisting  of  equipment  and  computer 
programs  collocated  and  interfacing  with  a  DSCS  Earth  Terminal. 

The  SCCE  provides  the  following  capabilities  for  operational 
command  and  control  of  two  active  and  one  standby  DSCS  satellites: 

a.  Generate  and  transmit  commands  and  command  sequences. 

b.  Acquire,  process,  record  and  display  telemetry  data. 

c.  Interface  with  DOSS 

d.  Interface  with  the  Air  Force  Satellite  Control  Facility 
(AFSCF)  for: 

(1)  Command  backup 

(2)  Generation  of  non-payload  related  commands 

(3)  Anomaly  resolution 

(4)  Orbital  parameter  support  to  the  SCCE 
2.2  GE/MODCOMP  Implementation 

2.2.1  Description 

To  accomplish  the  above  functions,  the  SCCE  is,  as  designed 
by  the  General  Electric  Corporation  (G.E.),  comprised  of  the 
following  major  subsystems  (refer  to  Figure  2-1) : 

a.  Control  and  Display/Computer  and  Peripheral  Subsystem 
(CD/CPS) 

b.  Telemetry  and  Command  Subsystem  (TCS) 

c.  Earth  Terminal  Interface/Checkout  Calibration  and  Test 
Subsystem  (ETI/CCTS) 
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Figure  2-1.  SCCE  Functional  Block  Diagram 


d.  Software  Subsystem  consisting  of  the  following  major 
programs : 

(1)  Telemetry  and  Command  Program 

(2)  Communications  Configuration  Program 

2.2.2  Control  and  Display/Computer  and  Peripheral  Subsystem 
(CD/CPS) 

The  Control  and  Display/Computer  and  Peripheral  Subsystem 
consists  of  the  computer  equipment,  and  associated  storage  and 
terminal  devices  (man-machine  interface)  required  to  support  the 
functions  described  above.  In  addition  to  providing  the  principal 
processing  capability  of  the  SCCE,  the  CD/CPS  provides  real  time 
control  of  functions  within  the  Telemetry  and  Command  Subsystem 
and  Earth  Terminal  Interface/Checkout  Calibration  and  Test 
Subsystem,  and  provides  control  and  status  monitoring  of  those 
subsystems. 

The  CD/CPS  consists  of  the  following  equipment: 

a.  MODCOMP  Classic  11/75  Computer  -  A  16-bit  machine  with  2 
megabytes  of  primary  storage. 

b.  Three  moving  head  disks  (MHD)  -  Each  MHD  is  capable  of 
storing  67  megabytes,  and  has  its  own  controller  to 
provide  data  base  redundancy  in  the  event  of  a 
malfunction. 

c.  Two  magnetic  tape  units  (MTU)  -  Each  MTU  is  a  9  track,  75 
inches  per  second,  800/1600  bits  per  inch  -  NRZI/Phase 
Encoded  unit  with  a  single  controller. 

d.  Parallel  and  serial  interface  devices. 
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Locations  are  provided  for  SCCE  operation  from  a  Payload 
Controller's  position  and/or  from  a  Maintenance  and  Analysis 
position.  These  positions  include  the  following  computer  terminal 
equipment: 

a.  Printer/Plotter  -  A  Versatec  V80  plotter  wth  200  data  per 
inch  resolution,  1.2  inches  per  second  paper  speed  and  a 
dot  matrix  printing  speed  of  1,000  lines  per  minute.  A 
separate  controller  provides  the  capability  for  plotting, 
printing,  and  hard  copy  display  from  the  Graphic  Display 
terminal. 

b.  Alpha-numeric  CRT  terminals. 

c.  Graphics  Display  terminal  -  A  Tektronix  4014-1  provides 
1920  characters  or  a  512  by  512  point  capability  for 
vector  and  graph  presentation. 

d.  Program  Function  Keyboard 

e.  Line  Printer. 

2.2.3  Telemetry  and  Command  Subsystem  (TCS) 

The  TCS  provides  the  following  functions: 

a.  Control  of  uplink  command  flow. 

b.  Control  up  downlink  telemetry  flow. 

c.  Control  of  Single  Channel  Transponder  (SCT)  telemetry 
information  flow. 

d.  Generation  of  IRIG  B  time  for  data  recording. 

e.  Analog  recording  of  telemetry  data. 

f.  Strip  chart  recording  of  telemetry  data. 

2.2.4  Earth  Terminal  Interface  Checkout  Calibration  and  Test 
Subsystem  (ETI/CCTS) 

The  ETI/CCTS  provides  the  following  functions: 
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a.  DSCS  Earth  Terminal  RF  interface. 

b.  Command  and  telemetry  interface  with  the  TCS. 

c.  Provisions  for  command  and  telemetry  self  check. 

d.  Calibration  and  self  check. 

2.3  SDCS  Requirements 

The  SDCS  is  required  to  provide  a  survivable  autonomous 
minimal  network  control  capability  for  the  operation  of  DSCS  III 
networks.  During  the  period  of  SDCS  operation,  it  is  assumed  that 
other  fixed  DSCS  operations  facilities  (e.g.,  DSCSOCs,  AFSCF)  are 
no  longer  available.  Hence  the  SDCS  must  provide  autonomous 
network  control  to  the  extent  possible. 

The  SDCS  must  provide  the  capability  to  perform  the  following 
three  major  control  functions: 

a.  Network  Control 

b.  Payload  Control 

c.  Satellite  Control 

Implementation  of  Network  Control  will  be  provided  by  the  DOSS 
System  and  the  DECS  System.  Payload  control,  i.e.,  the  control  of 
the  DSCS  III  satellite  communication  payload,  will  be  provided  by 
the  SCCE.  In  addition,  the  SCCE  will  provide  control  of  the 
satellite  platform. 

SDCS  Limitations 

The  SDCS  will  operate  with  a  single  terminal.  This  will 
limit  the  SDCS  to  the  support  of  a  single  DSCS  satellite.  This  is 
in  contrast  to  the  usual  operation  of  a  DSCSOC  which  concurrently 
supports  two  DSCS  satellites  (see  Table  2-1) .  The  SDCS  will  be 
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in  a  trailer  with  considerably  less  space  than  is  found  in  the 
DSCSOC.  Consequently,  fewer  operations  personnel  will  be  present 
in  the  SDCS,  resulting  in  less  terminal  and  peripheral  equipment, 
some  of  which  is  shared  among  the  SDCS  systems.  Because  the  SDCS 
configuration  is  transportable,  the  SDCS  environmental 
requirements  are  more  stringent  (e.g.,  shock,  vibration,  dust) 
than  that  of  a  DSCSOC.  Consequently,  militarized  equipment  will 
be  used. 


Table  2-1.  Functional  Requirements/Capability 


DSCSOC 

SDCS 

GENERATE  AND  TRANSMIT  COMMANDS 

GENERATE  &  TRANSMIT  COMMANDS 

ACQUIRE  &  PROCESS  TELEMETRY 

DATA  FOR  2  ACTIVE  SATELLITES 
PROVIDE  DATABASE  FOR  3rd 

SATELLITE 

ACQUIRE  &  PROCESS  TELEMETRY  DATA 
FOR  1  ACTIVE  SATELLITE 

PROVIDE  DATABASE  FOR  2nd 

SATELLITE 

INTERFACE  WITH  DOSS 

INTERFACE  WITH  DOSS 

INTERFACE  WITH  SCF 
o  COMMAND  BACKUP 
o  NON-PAYLOAD  COMMAND 

GENERATION 

o  ANOMALY  RESOLUTION 

O  ORBITAL  PARAMETER  INPUT 

PROVIDE  AUTONOMOUS 

0  NON-PAYLOAD  COMMAND 

GENERATION 

0  ANOMALY  RESOLUTION 

0  ORBIT  DETERMINATION 

2.4  SDCS/SCCE  MIL  VAX  DESIGN 

The  SDCS/SCCE  will  include  the  previously  described  ETI/CCTS 
and  the  TCS,  each  suitably  modified  to  accommodate  the  MIL  VAX 
computer  interface.  In  addition,  these  subsystems  will  contain 
only  that  equipment  needed  for  the  support  of  a  single  satellite. 
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The  Control  Display/Computer  and  Peripheral  Subsystem 
(CD/CPS)  will  be  based  on  a  MIL  VAX  I  computer  supported  by 
appropriate  terminals  and  peripherals.  The  CD/CPS  will  support  a 
single  DSCS  III  satellite  and  will  maintain  a  data  base  for  a 
second  (backup)  DSCS  III  satellite.  Switchover  from  one  active 
satellite  to  the  second  (backup)  satellite  will  be  accomplished  in 
less  than  15  minutes.  This  time  is  established  by  the  time 
required  to  re-orient  the  SDCS's  single  antenna  to  the  backup 
satellite  and  to  recognize  the  satellite's  IF  signals.  Because  of 
the  reduced  floor  space  in  the  SDCS,  the  CD/CPS  will  be  supported 
by  ruggedized  rack  mounted  disk  units. 

The  Man-Machine  Interface  (MMI )  will  consist  of  a  Maintenance 
and  Analysis  Operator's  Position  located  in  the  SDCS  van  and  a 
Payload  Controller's  Position  located  outside  the  van  and 
connected  by  a  fiber  optic  interface  for  the  purpose  of  this 
study.  This  remote  interface  has  been  considered  as  not  affecting 
the  processing  which  supports  the  terminal  devices  listed  in  Table 
2-2. 


Table  2-2.  SDCS/SCCE  Terminal/Peripheral  Devices 


Type 

Payload 

Controller 

Maint/ 

Analysis 

Total 

Alphanumeric/Graphics  CRT^- 

2 

2 

4 

Pr in ter /PI otter 

1 

1 

2 

Strip  Chart  Recorder 

1 

1 

Disk  Drive 

2 

Magnetic  Tape  Unit 

l2 

*  Includes  programmable  function  keyboard  capability 
2  Shared  with  DECS 
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It  has  been  assumed  that  all  SCCE  FORTRAN  programs  will  be 
readily  converted  to  run  on  the  MIL  VAX  computer,  and  that  all 
assembler  programs  will  be  rewritten  for  the  MIL  VAX.  In  the 
rehosting  of  this  software,  CSC  has  assumed  that  the  number  of 
lines  of  code  obtained  will  not  differ  significantly  from  the 
lines  of  code  in  the  MODCOMP  implementation. 

2.5  DSCSOC  Requirements 

If  the  SCCE  software  is  rehosted  to  a  MIL  VAX,  then  it  can  be 
assumed  that  the  MIL  VAX  version  of  the  software  will  be  capable 
of  being  run  on  a  DEC  VAX  computer  with  minimal  conversion 
effort.  Thus  the  creation  of  a  DEC  VAX  based  SCCE  for  operation 
in  the  DSCSOC  will  require  hardware  changes  to  incorporate  a 
commercial  DEC  VAX  processor,  peripheral  devices,  terminal 
equipment  and  interface  converters  for  the  TCS  and  ETIS  equipment. 

The  functional  requirements  of  a  DEC  VAX  based  SCCE, 
operating  in  a  DSCSO°,  will  be  the  same  as  the  functional 
requirements  for  the  MODCOMP  based  SCCE.  The  DEC  VAX  system  in 
the  DSCSOC  will  be  required  to  concurrently  support  two  DSCS  III 
satellites  while  maintaining  a  data  base  for  a  third  satellite, 
with  provision  for  rapid  switchover  to  the  standby  satellite. 
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3.0  OBJECTIVE  OF  THE  STUDY 


3.1  SDCS  Design 

The  primary  objective  of  the  study  is  to  assess  the  rehosting 
of  the  SCCE  from  the  DSCSOC  MODCOMP  implementation  to  the  SDCS  MIL 
VAX  implementation.  The  assessment  is  to  include  hardware  and 
software  conversion  plus  both  quantitative  measures,  e.g.,  cost, 
and  qualitative  aspects,  e.g.,  "difficulty"  of  specific  code 
conversion. 

The  change  from  the  MODCOMP  computer  to  the  MIL  VAX  (or  any 
other  computer)  introduces  corresponding  changes  in  the 
hardware/software  interfaces  (to  the  Telemetry  and  Command 
Subsystem  and  to  the  Earth  Terminal  Interface  Subsystems) .  These 
changes  are  due  to  difference  in  computer  architecture,  computer 
word  size,  instruction,  etc.  The  basic  issue  to  be  answered  by 
this  study  is:  can  the  rehosting  of  the  SCCE  from  the  MODCOMP  to 
the  MIL  VAX  be  accomplished  in  a  way  that  permits  cost-effective 
re-use  of  the  applications  software  and  an  operationally  effective 
hardware  interface? 

Implicit  in  this  issue  are  the  following  elements: 

a.  Size  of  the  applications  software  (lines  of  code) . 

b.  Processing  load  of  the  applications  software  (number  of 
instructions  per  second) . 

c.  Primary  memory  needed  to  support  the  applications 
software  (KB) . 

d.  Secondary  memory  (disk  storage)  needed  to  support  the 
file  structure  (MB) . 

e.  Input/output  channel  capacity  needed  to  conduct  the 
necessary  processing  (KB/sec) . 
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f.  Availability  of  computer  resources  to  support  the  items 
above. 

g.  Relative  ease  (or  difficulty)  of  converting  or  rewriting 
the  applications  software. 

It  should  be  pointed  out  that  most  of  the  application 
software  is  written  in  FORTRAN  and,  therefore,  should  be  easily 
converted  to  the  MIL  VAX  environment.  However,  some  of  the 
applications  software  is  written  in  assembler.  This  code  must  be 
rewritten.  System  macros  must  also  be  rewritten. 

In  order  to  accomplish  this  assessment,  CSC  has  determined 
the  processing  load  (by  analyzing  source  code) ,  and  has  estimated 
storage  requirements  (both  primary  memory  and  disk) .  Also,  CSC 
has  designed  a  hardware  system  based  on  the  MIL  VAX  computer  and 
appropriate  ruggedized  peripherals.  In  some  aspects,  excess 
capacity  (over  the  original  MODCOMP  system)  has  been  incorporated 
to  use  readily  available  ruggedized  equipment.  This  achieves  some 
margin  of  safety  in  the  design  at  additional  cost.  CSC  has  sought 
to  design  a  "feasible"  system  for  the  purpose  of  identifying  the 
necessary  devices,  interface  adapters,  etc.  Optimization  of  cost 
vs  performance  has  not  been  done. 

In  conducting  this  assessment,  CSC  has  concentrated  on  the 
CD/CPS  and  the  interfaces  with  the  TCS  and  ETI/CTTS.  We  have 
assumed  that  the  characteristics  of  the  TCS  and  ETI/CTTS  do  not 
change  from  the  MODCOMP/DSCSOC  environment  to  the  MIL  VAX  SDCS 
environment. 

3.2  DSCSOC  Design.  A  secondary  objective  of  the  task  is  to 
assess  the  rehosting  of  the  SCCE  from  the  DSCSOC  MODCOMP 
implementation  to  a  DSCSOC  DEC  VAX  implementation,  assuming  that 
the  conversion  of  the  software  from  MODCOMP  to  MIL  VAX  has  already 
been  achieved.  This  assessment  includes  the  consideration  of 
hardware 
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and  software  conversion.  To  determine  the  processor  load,  CSC  has 
used  the  loading  analysis  developed  for  the  SDCS  MIL  VAX  system, 
suitably  modified  to  account  for  the  concurrent  processing  of  two 
satellites.  CSC  has  designed  a  hardware  system  based  on  a  DEC  VAX 
computer  and  appropriate  peripherals.  The  design  takes  advantage 
of  recent  cost-performance  improvements  in  computer  hardware  to 
include  more  main  memory  in  the  DEC  VAX  system  (6  MB)  than  is 
presently  in  the  MODCOMP  (2  MB).  Add-on  memory  costs  S2K/MB. 

This  design  also  assumes  that  the  characteristics  of  the  TCS 
and  ETI/CTTS  do  not  change  from  the  MODCOMP/DSCSOC  environment. 


4.0  MODCOMP  SYSTEM 


4.1  Current  GE  SCCE  System  Architecture 

Figure  4-1,  taken  from  GE  document  WPC-2429D-316D  (page  8) 
illustrates  the  SCCE  architecture  for  a  two  satellite  system. 

Only  the  CD/CPS  subsystem  is  of  interest  to  this  study  in  that  the 
study  objective  is  to  determine  the  feasibility  of  replacing  the 
MODCOMP  CLASSIC  11/75  computer  with  a  DEC  VAX  11/780  (DSCSOC)  and 
Norden  MIL  VAX-I  (SDCS) . 

Major  CD/CPS  interfaces  with  the  other  subsystems  and  systems 
are  given  in  Table  4-1:  the  majority  of  the  interfaces  are  RS232C 
asynchonous  lines  and  16-bit  parallel  interfaces  to  special 
purpose  devices.  Data  rates  on  these  lines  are  very  low  due  to 
their  being  synchronous  with  the  low  speed  telemetry  data  being 
transferred,  or  due  to  the  nature  of  the  devices  (even  when 
operated  at  device  capacity;  mostly  control  of  TCS/ETI 
equipments).  The  highest  data  rates  occur  for  disk,  tape,  and 
graphic  output  operations,  but  even  with  these  devices  operated  at 
full  speed,  I/O  limitations  are  not  expected. 

In  addition  to  determining  that  a  VAX  class  computer  can 
perform  satisfactorily  in  this  environment,  the  existence  of 
suitable  interface  controllers  must  also  be  determined.  The 
following  paragraphs  address  the  CD/CPS  areas  of  interest. 

4.1.1  MODCOMP  CLASSIC  11/75  Computer  System 

This  section  describes  the  MODCOMP  CLASSIC  11/75  Computer 
System  on  which  the  SCCE  system  is  currently  based.  It  is 
presented  to  inform  the  reader  of  the  current  hardware,  and  to 
present  the  significant  features  and  capabilities  the  Norden  MIL 
VAX  I  and  DEC  VAX  11/780  must  have. 


I 
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Figure  4-1.  SCCE  Architecture 
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l-l .  SCCE  Architecture  -  Two  Satellites 
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Table  4-1.  CD/CPS  Interfaces 


INTERFACE  POINT 

CD/CPS  INTERFACE  TYPE 

TCS  -  D/A  Converter 

1  "  “ 

16-bit  parallel  I/O 

TCS  -  TPU  #1 

16-bit  parallel  I/O 

TCS  -  TPU  #2 

16-bit  parallel  I/O 

TCS  -  TPU  #3 

16-bit  parallel  I/O 

TCS  -  SCT-TLM 

16-bit  parallel  I/O 

TCS  -  TCT 

16-bit  parallel  I/O 

TCS  -  TCG 

16-bit  parallel  I/O 

TCS  -  SIG.  MUX 

16-bit  parallel  I/O 

TCS  -  CIU  #1 

RS-232C ,  9600  bps 

TCS  -  CIU  #2 

RS-232C,  9600  bps 

TCS  -  SET  UP  TPU  #1 

RS-232C,  9600  bps 

TCS  -  SET  UP  TPU  #2 

RS-232C,  9600  bps 

TCS  -  SET  UP  TPU  #3 

RS-232C,  9600  bps 

TCS  -  TLM  SIMULATOR 

RS-232C,  9600  bps 

ETI  -  UP  CONVERTER  #1 

RS-232C,  9600  bps 

ETI  -  DOWN  CONVERTER  #1 

RS-232C,  9600  bps 

ETI  -  UP  CONVERTER  #2 

RS-232C,  9600  bps 

ETI  -  DOWN  CONVERTER  #2 

RS-232C,  9600  bps 

AFSCF  -  DATA  TRANSMISSION 

RS-232C,  9600  bps 

DOSS  -  DATA  TRANSMISSION 

RS-232C,  9600  bps 

4. 1.1.1  Central  Processor  Unit  (CPU) 

The  16-bit  oriented  CPU  has  a  fairly  standard  set  of 
instructions  expected  of  any  minicomputer  in  its  class. 

Instruction  formats  are  16-bit  words  (one  or  two,  as  applicable) , 
and  can  reference  both  fixed  point  and  floating  point  operands. 
Floating  point  operands  consist  of  a  9-bit  exponent  plus  22-bit, 
38-bit  or  54-bit  fractions  required  for  single,  double  or  triple 
precision  respectively.  An  Extended  Arithmetic  Unit  to  process 
such  floating  point  operations  is  integral  to  the  CPU.  Logical, 
shift,  compare  and  test,  branch,  control,  interrupt  and  call  as 
well  as  I/O  instructions  are  also  provided. 

Special  machine  instructions  are  provided  to  efficiently 
implement  some  FORTRAN  statements,  and  thereby  reduce  the  need  for 
some  assembly  language. 

Microprogramming  (by  customer)  is  possible  to  either  extend 
the  instruction  set,  or  to  achieve  faster  execution  of  high  usage 
f unctions. 

The  CPU  is  rated  at  0.96  MIPS  (million  instructions  per 
second) .  It  must  be  remembered  that  more  instructions  may  be 
required  on  a  16-bit  machine  (such  as  this  one)  to  equal  the  power 
of  one  on  a  32-bit  VAX.  Hence,  this  may  be  a  0.8  MIPS  machine 
when  compared  to  a  VAX  of  1.0  MIPS.  The  efficiency  of  the 
compiler  also  affects  this  number.  In  its  analysis,  CSC  has  used 
.96  MIPS  to  represent  the  MODCOMP  processing  rate.  The  equivalent 
16-bit  processing  rate  of  the  Norden  MILVAX  and  DEC  VAX  computers 
have  been  increased  by  20%  over  their  32-bit  performance. 

4. 1.1. 2  Primary  Memory 

Semiconductor  memory  is  used  and  has  a  maximum  size  of  two 
megabytes.  Memory  mapping  of  applications  modules  to  utilize 
scattered  pages  of  real  memory  is  used  to  increase  efficiency  of 
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memory  usage.  It  is  to  be  noted  that  although  the  literature 
refers  to  virtual  addressing,  the  Classic  11/75  does  not  offer 
virtual  memory  in  the  sense  of  paging  to  accommodate  very  large 
programs  without  programmer  control. 

Memory  addresses  can  be  interleaved  up  to  four  ways  among 
memory  modules  to  achieve  a  cycle  time  of  125  nanoseconds  per  16- 
bit  word.  While  this  is  faster  than  the  MIL  VAX  I  and  VAX-11/780, 
the  internal  data  bus  of  Classic  11/75  is  only  half  as  wide  as  in 
a  VAX  and  consequently  the  VAX  units  can  more  than  make  up  their 
slower  effective  cycle  time.  There  is  no  cache  memory. 

Error-correcting  MOS  memory  is  used  to  detect  and  flag 
multiple  bit  errors  and  to  correct  all  single  bit  errors. 
Diagnostic  circuitry  and  status  registers  are  used  to  diagnose 
memory  errors  and  provide  automatic  fault  isolation.  Memory  usage 
is  described  in  Table  4-2. 

4. 1.1. 3  I/O  Subsystem 

The  CLASSIC  11/75  system  for  SCCE  uses  two  I/O  Processors 
( ioP)  which  can  access  memory  directly  to  retrieve  or  store  data 
involved  in  I/O  to  peripheral  devices.  Each  IOP  has  two  I/O 
busses  which  operate  at  up  to  two  megabytes  each.  A  wide  variety 
of  MODCOMP  interfaces  are  available  for  attachment  to  the  I/O 
busses.  For  the  SCCE,  the  following  are  used  for  interface  types 
to  the  telemetry  and  earth  terminal  equipments. 

MODCOMP  4805-2  Parallel  16-bit  I/O  interface 

MODCOMP  4806  RS  232C  line  controller  (up  to 

16  lines) 

Printers,  printer-plotters,  disk,  and  tape  devices  use 
specifically  designed  controllers. 


Table  4-2.  Memory  Usage  -  MODCOMP  CLASSIC  11/75 


I 

I 

I 

( 

I 

I 

I 

I 

I 

I 

I 

I 


Memory  User 

Memory 

(Bytes) 

1  Satellite 

2  Satellites 

Permanently  Resident: 

Operating  System 

128K 

128K 

Fortran  Runtime  Library 

30K 

30K 

Common 

70K 

140K 

SRE 

25K 

25K 

Telemetry  Acquisition 

70K 

140K 

Beacon  Acquisition 

30K 

60K 

SUBTOTAL 

353K 

523K 

Temporarily  Resident 

Tasks 

1 ,593K 

2 ,688K 

Overlays 

1 , 407K 

2 , 397K 

SUBTOTAL 

3 , 000K 

5 ,085K 

Total  All  Software 

3 , 353K 

5 ,608K 

Physical  Memory  Available 

2 , 000K 

2 ,000K 

Remaining  Memory  (If  all  S/W  is 

resident) 

Not 

Not 

Feasible 

Feasible 

Remaining  Memory  for  Dynamic 

Allocation  of  Temp,  Res.  Tasks 

1 , 647K 

1 , 477K 
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4. 1.1. 3.1  MODCOMP  Parallel  I/O  Interfaces 

The  MODCOMP  4805-2  parallel  16-bit  interface  controller  is  a 
general  purpose  unit  which  provides  an  interface  to  a  user  s 
device  for  control,  status,  and  data  transfers.  There  are  16 
input,  16  output,  6  command,  and  7  external  status  lines  which  may 
be  used  for  device  interfacing.  Additionally,  spare  printed 
circuit  board  space  is  available  for  the  user  to  implement  special 
logic  on  the  controller  rather  than  in  the  device,  if  preferred. 
Table  4-3,  MODCOMP  4805-2  Parallel  I/O  Interface  Signals,  presents 
the  signals  the  user  has  available  to  work  with  for  interfacing  to 
user  devices. 

Parallel  16-bit  I/O  interfaces  are  used  as  indicated  in  Table 
4-3.  A  comparison  table  showing  parallel  interface  controller 
signals  for  both  MODCOMP  and  Norden  DEC  systems  is  presented  in  a 
later  section.  It  will  be  noted  that  some  conversion  engineering 
probably  will  be  necessary  to  interface  the  telemetry  and  earth 
terminal  equipment  to  the  VAX-type  computers. 

4. 1.1. 3. 2  MODCOMP  RS232C  Line  Controller 

The  MODCOMP  4806-X  Asynchronous  Terminal  Controller  can 
accommodate  up  to  16  RS232C  asynchronous  lines  added  in  groups  of 
four  lines  at  a  time.  The  following  features  are  provided: 

o  Programmable  data  rate  (19.2kb/s  maximum) 

o  Receive  break  detect 

o  Programmable  frame  size,  stop  bits  and  parity  bit 
o  Echoplex  Mode 
o  Channel  wraparound 

o  Limited  modem  control 

o  Transmitter  single  buffer  capability  (switch  selectable) 
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Table  4-3.  MODCOMP  4805-2  Parallel  I/O  Interface  Signals 


MODCOMP 

CLASSIC  11/75 

DESCRIPTION 

IBD00-IBD15 

16  input  data  bits 

OBI 00-0B15 

16  output  data  bits 

EXTSIN 

Interrupt  Control 

LDIBFN 

Load  input  strobe 

ODSTBN 

Strobe  generated  on  output  data  ready 

Strobe  indicating  CPU  has  taken  user  data 

Combination  status  and  command  bits 

CB10N-CB15N 

Command  bits  (6) 

IST03N ,  05N, 

Status  bits  (7) 

11N-15N 

(03N  indicates  device  on) 

(05N  normally  device  error) 

— 

True  whenever  UNIBUS  is  initialized 

OCSTBN 

Output  command  ready  strobe 

ODACCN 

Device  signals  output  data  has  been  accepted 

INBMTN 

Signals  device  that  input  data  buffer  is 
empty.  CPU  has  taken  data  (level  signal, 
not  pulses) 

OBFFN 

Output  ready  for  device 

BUSYN 

Device  busy  status  bit 

INHBCN 

Signal  to  prevent  loading  more  input 
data  from  device  until  CPU  has  taken 
data 

4-8 


Signal  levels,  waveforms,  timing  etc.  are  in  accordance  with  the 
El A  RS-232C  specifications.  These  lines  operate  intermittently  at 
rates  of  9600  bps. 

4. 1.1. 4  Peripheral  Storage  Devices 

Two  major  peripheral  storage  devices  are  used  in  the  CLASSIC 
11/75  configuration  within  the  SCCE.  These  are  the  MODCOMP  4195-2 
magnetic  tape  subsystem  and  the  MODCOMP  4178-2  Disk  Drive 
subsystem. 

4. 1.1. 4.1  MODCOMP  4195-2  Magnetic  Tape  Subsystem 

The  MODCOMP  4195-2  magnetic  tape  subsystem  consists  of  a  tape 
controller  and  daisy  chain  of  up  to  three  magnetic  tape  drive 
units.  Each  transport  is  a  75  inch  per  seconds  drive  with 
selectable  recording  densities  of  800  or  1600  bits  per  inch. 
Transfer  rate  is  120KB/sec.  Tapes  are  one-half  inch  wide, 

9-track,  and  are  IBM  compatible.  A  tape  formatter  within  the 
controller  allows  the  recording  modes  to  be  phase-encoded  or 
non-return  to  zero  (inverted). 

4. 1.1. 4. 2  MODCOMP  4178-2  Moving  Head  Disk  Subsystem 

This  dual  ported  magnetic  disk  drive  used  in  the  configuraton 
has  a  formatted  capacity  of  67  MB,  average  access  time  ( AAT )  of  30 
ms,  and  I/O  transfer  rate  of  up  to  1.2  MB  per  second.  Each  disk 
has  its  own  controller,  and  daisy  chains  to  one  or  more  disks  in 
order  to  ensure  disk  access  sh  1d  either  an  input/output  device 
or  disk  controller  malfunction.  In  the  current  SCCE 
configuration,  one  disk  is  used  exclusively  as  a  system  disk,  one 
is  used  exclusively  as  a  DSCS  data  disk,  and  the  third  is  an 
on-line  spare  ready  for  use  if  one  of  the  operational  disks 
malfunctions . 

4. 1.1. 5  MM I  Peripheral  I/O  Devices 

Peripheral  devices  used  to  interact  with  users  during 
operation  include  the  following: 
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4. 1.1. 5.1  VT100  Alphanumeric  Terminals 

DEC  VT100  Alphanumeric  Terminals  are  used  to  interface  to 
controllers  in  SCCE  operational  positions.  These  are  standard 
monochrome  RS232C  devices  operated  at  9600  bps,  and  are  used  to 
enter  system  commands,  data,  and  receive  data/reports. 

4. 1.1. 5.2  Tektronix  4014-1  Graphic  Terminal 

Tektronix  4014-1  Graphics  Terminals  include  a  display, 
standard  keyboard  and  a  programmable  function  keyboard  (PFK)  (32 
keys) .  Primary  usage  is  for  graphics  displays  such  as  satellite 
"footprint"  plots  etc.  To  save  keystrokes  and  provide  ease  of 
operation,  certain  functions  can  be  invoked  by  pushing  specific 
keys  on  the  PFK  keyboard.  When  pushed  and  function  selected,  a 
lamp  at  that  key  is  illuminated. 

The  terminal  interfaces  to  the  computer  system  by  means  of  an 
RS232C  asynchronous  line  operating  at  9600  bps.  Another  RS232C 
line  interfaces  the  terminal  to  a  Versatec  C-TEX-5  Graphics  CRT 
Controller  which  enables  transfer  of  graphic  CRT  data  to  the 
Versatec  V80  Printer/Plotter.  The  C-TEX-5  is  an  electronic  switch 
which  selects  either  the  terminal  or  a  printer/plotter  interface 
from  the  computer  system  as  the  source  of  graphic  print 
information  for  the  V80  printer.  When  one  device  is  selected,  the 
printer  accepts  data  from  that  device  and  appears  busy  to  the 
other . 

4. 1.1. 5. 3  Versatec  V80-11  Printer/Plotter 

The  Versatec  V80  Printer/Plotter  is  used  to  function  both  as 
a  printer  and  as  a  plotter  (through  dot-line  printing).  Use  of 
dot-line  printing  enables  the  V80  to  display  any  kind  of  graphics 
since  the  page  image  (including  plots)  is  printed  a  line  at  a  time 
(1/200  of  an  inch  resolution) .  Plotting  is  performed  at  a  rate  of 
one  inch  per  second. 


In  the  print  mode,  the  V80  prints  132  character  lines  at  the 
rate  of  1000  characters  per  inch.  Paper  width  is  eleven  inches 
for  both  modes. 

Interface  to  the  computer  is  through  a  Versatec  C-TEX-5 
Graphics  CRT  Controller  and  in  turn  to  a  MODCOMP  printer  plotter 
interface.  The  C-TEX-5  allows  the  computer  system  and  a  single 
graphics  terminal  (RS232C)  to  share  the  V80  Printer  Plotter. 

4. 1.1. 5. 4  MODCOMP  4242-21  Printer 

The  MODCOMP  4242-21  impact  line  printer  (manufactured  by  Data 
Products,  Inc.)  is  a  132  column,  1000  lines  per  minute  device. 
Character  set  is  64  character  ASCII.  Paper  widths  up  to  B  size 
(14-3/4  inches)  can  be  accommodated. 

4.2  SCCE  Disk  Storage 

Three  67MB  disks  are  used  (Figure  4-2) .  The  System  Disk  is 
fully  loaded  with  operating  system,  spooler,  roller,  batch  and 
scratch  files.  The  operating  system  files  include  the  MODCOMP 
operating  system,  system  load  modules,  applications  load  modules, 
systems  source  library  and  FORTRAN  library.  The  Data  Disks 
contain  the  files  needed  to  support  the  applications  software. 

All  three  satellite  data  bases  are  located  on  Data  Disk  1.  Data 
Disk  2  provides  a  backup  capability  to  be  used  in  case  of  disk 
channel  failure  or  controller  failure. 

4.2.1  SCCE  Files 

The  basic  SCCE  file  structure  for  the  MODCOMP  implementation 
is  described  in  Table  4-4.  Files  are  either  uniquely  associated 
with  a  specific  satellite  (either  active  or  standby)  or  are  fixed 
in  size  for  the  SCCE  as  a  whole.  As  Table  4-3  shows,  about  15  MB 
Bytes  of  storage  are  required  to  support  each  satellite,  and  an 
additional  4.5  MB  completes  the  SCCE  files.  This  file  structure 
is  not  changed  for  the  MIL  VAX  or  DEC  VAX  based  systems. 

4.3  Software 

The  MODCOMP  based  software  is  described  in  Section  5. 
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Table  4-4.  SC 


CPCI 

FILE 

CATEGORY 

TCP 

MIF 

STATIC 

DYNAMIC  USER 
DYNAMIC  DATA 
HISTORY 
CATALOG 

DEFINED 

STORAGE 

SUBTOTAL 

CCP 

STATIC 

USER  DEFINED 
DATA  STORAGE 

SUBTOTAL 

SCCE 

TOTAL 

1  Active  Satellite 
|  1  Standby  Satellite 


2  Active  Satellites 
1  Standby  Satellite 


File  Description 


FIXED 

(KB) 

PER  SATELLITE 
(KB) 

TOTAL 

(KB) 

650 

200 

345 

200 

3,100 

19 

11,100 

256 

27 

4,514 

11,383 

2,500 

35 

580 

3,115 

4,514 

14,498 

- 

4,514 

28,996 

33,510 

4,514 

43,494 

48,008 

L3 


5.0  SOFTWARE 


5.1  Software  Description 

5.1.1  General 

The  SCCE-unique  software  consists  of  applications  software 
which  performs  the  functions  of  the  SCCE  and  systems  software 
which  adapts  the  computer  to  the  specific  configuration  used.  The 
software  is  summarized  in  Table  5-1.  The  Lines  of  Code  listed  in 
Table  5-1  are  for  the  IPM  SCCE  which  supports  a  single  active 
satellite.  The  PSCCE  uses  functional  duplicates  of  much  of  the 
IPM  software  to  support  a  second  active  satellite.  The  functional 
duplicates  do  not  require  independent  conversion  for  rehosting, 
though  they  do  add  configuration  management  efforts. 

5.1.2  Applications  Software 

5. 1.2.1  Computer  Program  Configuration  Items 

The  SCCE  applications  software  consists  of  two  Computer 
Program  Configuration  Items  (CPCIs) :  Telemetry  and  Command 
Program  (TCP)  and  Communications  Configuration  Program  (CCP) . 

Each  CPCI  consists  of  multiple  Computer  Program  Components  (CPC's) 
which  are  linked  together  to  form  the  executable  program.  Also 
included  in  the  applications  software  are  the  utilities  and  common 
data  variables  necessary  to  support  each  CPCI. 

5. 1.2. 2  Telemetry  and  Command  Program 

The  Telemetry  and  Command  Program  provides  the  following 
capabilities  for  the  DSCS  III  satellite  from  the  SCCE: 

a.  Commanding  of  all  satellite  subsystems,  including  the 
Communications  Subsystem. 

b.  Acquisition  and  processing  of  the  satellite  telemetry 
data. 

c.  Performance  analysis  of  the  satellite  subsystems. 

d.  Configuration  and  control  of  the  ground  station. 
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Table  5-1.  SCCE  Software  Summary 


SOFTWARE  ELEMENT 

FORTRAN 

ASSEMBLER* 

LINES 

LINES 

APPLICATIONS 

TCP 

57,404 

688 

CCP/ORBIT 

29,415 

0 

UTILITIES 

17,383 

3,888 

COMMON 

11,000 

0 

COMMENTS 

115,780 

5,000 

UNEXECUTABLE  CODE** 

11,580 

0 

AUXILIARY  EXEC.  ROUTINES 

0 

26,406 

TOTAL  (APPLICATIONS) 

242,562 

35,982 

SYSTEM 

MACROS 

0 

22,400 

PROCEDURES 

0 

5,300 

TOTAL  (SYSTEM) 

27,700 

TOTAL-SCCE 

242,562 

63,682 

*  ^Includes  all  machine  unique  code 

I  ** FORMAT ,  DATA,  specification  statements 
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e.  Jammer  detection. 

f.  Verification  of  the  Configuration  of  the  Multiple  Beam 
Antennas  (MBAs) . 

g.  Operator/Controller  training  assistance. 

The  TCP  software  system  executes  under  the  control  of  the  SCCE 
operators  and  controllers.  The  operating  system  and  the  auxiliary 
executive  functions  provide  executive  and  input/output  routines 
for  the  applications  software  modules.  Executive  routines  include 
task  scheduling  and  dispatching  on  a  priority  basis,  interrupt 
handling,  and  memory  and  device  allocations.  Input/output 
routines  include  communication  with  the  CRTs  and  keyboards,  data 
transfers  to  and  from  the  SCCE  ground  station  hardware,  file 
management  services,  and  printed  outputs. 

The  TCP  functions  are  divided  into: 

a.  Real  time  functions. 

b.  Regularly  scheduled  functions. 

c.  Support  functions. 

d.  Utilities. 

Many  of  the  real  time  and  regularly  scheduled  functions  can  be 
initiated  at  any  time  by  a  request  from  the  operator. 

The  real  time  (R/T)  TCP  functions  consist  of  Telemetry 
Acquisition,  R/T  Satellite  Performance  Evaluation  provided  by  the 
Telemetry  Processing  and  MBA  Configuration  Verification  functions, 
R/T  Command  Generation  and  Transmission,  Jammer  Detection,  and  R/T 
Display  Generation.  These  functions  are  performed  by 
core-resident  and  interactive  modules  which  execute  in  the 
computer  memory  concurrently.  Among  the  R/T  functions.  Telemetry 
Acquisition  has  the  highest  priority  with  Command  Management  the 
next  highest.  R/T  Display  Generation  has  the  lowest  priority. 
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The  regularly  scheduled  TCP  functions  consist  of  Subsystem 
Analysis,  Activity  Report  Generation,  and  Archival/Reload.  These 
functions  are  all  regularly  scheduled  on  data  span  termination 
(i.e.,  approximately  every  two  hours).  They  share  the  computer 
memory  and  resources  with  the  R/T  functions.  Therefore,  since 
their  priorities  are  lower,  they  execute  when  the  R/T  functions 
are  awaiting  external  input  requests.  Among  the  regularly 
scheduled  functions.  Archival  has  the  highest  priority  and 
Activity  Report  Generation  the  lowest. 

The  support  functions  for  the  TCP  CPCI  consist  of  Static  Data 
Base  Generators,  Command  Sequence  Generators,  the  Inter-Site  Data 
Transfer  Function,  and  the  Training  Scenario  Generator.  The 
support  functions  use  the  executive  and  I/O  routines  provided  by 
the  Operation  System  and  the  Auxiliary  Executive  functions  to 
generate  the  data  base  required  by  the  on-line  functions  from 
operator  inputs,  and  to  list  and  display  data  and  generate  reports 
from  the  data  base  for  use  by  the  operations  personnel. 

The  TCP  utility  functions  consist  of  routines  to  perform  bit 
manipulation,  file  accesses,  output  formatting,  numerical 
conversions,  and  error  displays.  These  functions  are  invoked  by 
other  TCP  functions.  Therefore,  their  priorities  vary  according 
to  the  priority  level  of  the  routine  making  the  call. 

5. 1.2. 3  Communications  Configuration  Program 

The  Communications  Configuration  Program  provides  the 
following  capabilities  during  various  phases  of  the  DSCS  III 
mission: 

a.  Communications  subsystem  configuration  control. 

b.  Control  and  analysis  of  the  three  MBAs. 

c.  Control  and  analysis  of  the  Gimballed  Dish  Antenna. 

d.  Support  of  the  above  functions. 
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The  CCP  software  system  executes  under  the  control  of  the 
SCCE  Operators  and  Controllers.  Operator  requests  are  handled  by 
the  Sequence  and'  Control  function.  Each  CCP  function,  once 
initiated,  interacts  with  the  operator  directly  using  the  command 
CRT  for  those  inputs  required  for  execution. 

The  communications  subsystem  configuration  control  CCP 
functions  consist  of  Antenna  Connection,  Primary/Redundant 
Component  Selection,  Jammer  Detection  Mode  Selection,  Transponder 
Channel  Gain,  RLM  (Receive  Level  Monitor)  Mode  Selection,  and 
Frequency  Shift  Selection.  The  control  and  analysis  of  the  three 
MBA's  and  Gimballed  Dish  Antenna  CCP  functions  consist  of 
Selective  Coverage,  Jammer  Nulling,  Multiple  Beam  Antenna  Command 
Sequence  Generation,  MBA  Plotting,  and  Gimballed  Dish  Antenna 
Control.  The  CCP  support  functions  consist  of  Jammer  Location, 
Ephemeris  and  Ranging  Data  Generation,  Message  Encode/Decode 
Input/Output  Handles,  Static  Data  Base  Generation,  and  Sequence 
and  Control. 

The  CCP  software  system  is  an  off-line,  interactive,  menu 
driven  program.  It  is  operated  by  keying  in  responses  to  menus 
and  prompts  displayed  on  any  graphics  or  alphanumeric  CRT  to  which 
the  System  Request  Executive  has  access. 

Table  5-2  summarizes  the  number  of  Computer  Program 
Components  (CPCs)  and  lines  of  FORTRAN  and  Assembly  code  for  each 
software  system.  Table  5-3  lists  the  CPCs  having  embedded 
Assembler  code.  Note  that,  in  general,  the  number  of  lines  of 
comments  is  slightly  greater  than  the  number  of  lines  of 
executable  code. 

5.1.3  System  Software 

The  system  software  consists  of  macros  and  procedures. 
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Table  5-2.  Application  Software  Summary 


SOFTWARE  ELEMENTS 

CPCs 

FORTRAN  LINES* 

ASSEMBLER  LINES* 

TCP: 

REAL-TIME  FUNCTIONS 

502 

14,027 

674 

REGULARLY  SCHEDULED 

FUNCTIONS 

137 

8,790 

0 

SUPPORT  FUNCTIONS 

138 

14,579 

14 

TCP  TOTAL 

777 

57,404 

688 

CCP  FUNCTIONS 

179 

29,415 

0 

UTILITIES 

253 

17,383 

3,888 

COMMON 

- 

11,000 

0 

COMMENTS 

N/A 

115,780 

5,000 

UNEXECUTABLE  CODE** 

N/A 

11,580 

0 

AUXILIARY  EXEC.  ROUTINES 

N/A 

0 

26,406 

TOTAL 

1209 

242,562 

35,982 

♦Excluding  Comments,  Unexecutable  Code 
♦♦FORMAT,  DATA,  Specification  Statements 


Table  5-3.  CPCs  With  Embedded  Assembler 


LOAD  MODULE 

CPC 

LINES  OF 

EMBEDDED  ASSEMBLER 

CMDCT 1-CMDVF 1 

TCM241 

19 

CMDCTl 

TCM245 

13 

CMDCTl 

TCM24B 

25 

CMDCTl 

TCM300 

14 

CMDSEG 

TCG110 

14 

CMDVF1 

TCT3B1 

59 

CMDVFl 

TCT3B2 

34 

CMDVFl 

TCT3B3 

88 

SRE 

TEX150 

24 

SRE 

TEX170 

5 

SRE 

TEX180 

16 

TOTAL 

311 

5. 1.3.1  Macros 


( 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 
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Many  of  the  operations  that  the  MODCOMP  operating  system 
performs  on  behalf  of  the  user  are  implemented  as  tasks  called 
system  services.  Most  of  these  tasks  are  linked  as  part  of  the 
executive  and  reside  in  system  space;  others  are  contained  in 
privileged  libraries.  Some  services  are  invoked  directly  by  the 
application  programs.  Others  are  called  on  behalf  of  the  user 
bythe  MODCOMP  operating  system.  MODCOMP  System  services  performs 
the  following  functions: 

o  Task  Scheduling 

o  Inter-task  communication 

o  Memory  Allocation 

o  Logical  I/O  Handling 

o  File  Manager 

o  Operator  Communication 

o  Program  Development  Facility 

o  High  Level  Language  Support 

o  Task  loading 

o  Automatic  roll-in/roll-out 

Software  has  been  developed  to  perform  some  of  these 
functions.  These  system  software  routines  are  known  as  macros, 
written  in  MODCOMP  assembly  language.  A  brief  description  of 
typical  macros  is  given  below. 

COMMAC .  This  macro,  the  Communication  Macro,  transmits 

variable  length  collections  of  data  between  tasks. 
Messages  flow  along  distinct  communication  paths 
known  as  channels.  Tasks  use  the  message  service  for 
synchronization  as  well  as  information  transfer. 
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FMAMAC 


the  File  Manager  Macro,  FMAMAC  organizes,  maintains 
and  services  multilevel  files.  File  Manager  also 
supports  FMLIST  (List  Utility)  and  FMSADE 
(Save/Restore  Utility)  which  operate  as  a  standard 
processor  within  the  File  Manager  Subsystem. 

L I OMAC  Logical  I/O  System  Macro  performs  task  scheduling  and 
monitors  I/O  transactions  to  peripheral  controllers. 

Many  of  these  functions  may  be  provided  by  a  computer 
operating  system,  e.g.,  VAX/VMS.  CSC  is  unable,  at  this  time,  to 
state  how  many  of  these  functions  will  be  rewritten.  In  costing 
and  conversion  estimates,  CSC  has  assumed  the  worst  case,  that  all 
macros  must  be  reprogrammed. 

5. 1.3. 2  Procedures 

A  procedure  or  command  procedure  is  a  file  containing  a 
predefined  sequence  of  commands  to  perform  certain  actions. 

Common  uses  for  a  command  procedure  include  constructing  sequences 
of  commands  one  frequently  uses  during  interactive  terminal 
sessions,  and  defining  a  batch  job  stream  to  submit  from  a 
terminal  session  or  a  system  card  reader.  In  its  simplest  form,  a 
command  procedure  consists  of  one  or  more  command  lines  for  the 
command  interpreter  to  execute.  The  command  procedures  are 
written  in  MODCOMP  command  language. 

Examples  of  the  functions  performed  by  MODCOMP  procedures  are 

a.  Build  a  batch  job. 

b.  Create  a  disk  file. 

c.  Update  a  system  library. 

d.  Create  a  single  system  disk. 

These  procedures  are  machine  dependent.  They  will  have  to  be 
rewritten  for  each  machine  on  which  the  SCCE  is  hosted. 
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5.2  Software  Portability  and  Conversion 

A  major  problem  with  program  conversion  is  that  compiler 
dialects  for  the  same  language  may  differ  among  different 
vendors.  The  VAX-11  MVS  FORTRAN  and  the  MODCOMP  NASA  EXTENDED 
FORTRAN-78  are  both  based  on  the  American  National  Standard  (ANS) 
FORTRAN  X3. 9-1978;  however,  there  are  certain  incompatibilities 
between  the  two  FORTRAN  implementations.  These  incompatibilities 
are  described  in  Sections  5.2.1  through  5.2.4.  MODCOMP  FORTRAN 
programs  can  be  modified  so  that  they  produce  the  intended  result 
under  the  VAX-11  FORTRAN  compiler. 

FORTRAN  programs  consist  of  FORTRAN  statements,  which  define 
a  computing  procedure,  terminated  by  an  END  statement  and  optional 
comments.  Statements  can  be  grouped  into  two  general  classes, 
executable  and  nonexecutable,  which  are  described  in  the  following 
sections . 

5.2.1  Nonexecutable  Statements 

This  section  describes  the  nonexecutable  incompatible 
statements  that  will  require  a  minimum  conversion  effort. 
Nonexecutable  statements  describe  data  arrangements  and 
characteristics,  and  provide  editing  and  data-conversion 
information . 

5. 2. 1.1  Debug  Statement  Indicator 

Debug  statements  are  FORTRAN  statements  that  are  treated  as 
source  text  or  comments  by  some  compilers,  depending  on  the 
compiler  directive  that  is  specified.  The  MODCOMP  FORTRAN 
programs  under  review  use  a  letter  "X"  in  column  1  to  designate 
debug  statements.  The  VAX-11  FORTRAN  compiler  will  allow  the  use 
of  the  letter  "D"  in  column  1  to  designate  debugging  statements. 
Each  continuation  line  of  a  debug  statement  must  have  the  letter 
"D"  in  column  1  as  well  as  the  continuation  indicator  in  column  6. 
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5. 2. 1.2  INCLUDE  STATEMENT 


The  INCLUDE  statement  causes  the  contents  of  a  designated 
file  to  be  incorporated  in  the  FORTRAN  compilation  directly 
following  the  INCLUDE  statement.  The  specifications  of  the  VAX-11 
FORTRAN  and  the  MODCOMP  FORTRAN  are  somewhat  different  as 
described  in  Table  5-4. 

Table  5-4.  INCLUDE  Statement 


MODCOMP  FORTRAN 


VAX-11  FORTRAN 


INCLUDE  dir/file, list-option,  INCLUDE  'file  specification/ 
rewind-option  list-option' 

File  specifications  in  VAX  have  the  form:  [directory]  file 
name. file  type .version . 

directory  identifies  the  name  of  the  directory  under  which 
the  file  is  cataloged.  Directory  name  can  be 
delimited  with  a  square  or  angular  bracket. 

filename  identifies  file  by  its  name.  It  can  be  9 

characters  long. 

filetype  describes  the  kind  of  data  in  the  file;  it  can 
be  up  to  3  characters  long. 

version  defines  which  version  of  the  file  is  desired. 

Versions  are  identified  by  a  decimal  number. 


In  MODCOMP  FORTRAN  an  INCLUDE  statement  provides  both  the 
list  and  the  rewind  option.  However,  a  FORTRAN  INCLUDE  statement 
in  VAX  provides  only  the  list  option. 

The  VAX-11  FORTRAN  INCLUDE  statement  is  limited  to  40  continuation 
lines . 
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5. 2. 1.3  Explicit  Type  Statements 


MODCOMP  FORTRAN  provides  for  the  explicit  definition  of  real 
variables  in  4,  6  or  8  bytes;  however,  VAX-11  FORTRAN  only 
provides  for  an  explicit  real  variable  of  4  and  8  bytes.  MODCOMP 
FORTRAN  explicit  REAL*  6  variables  should  be  changed  to  REAL*  8 
variables  for  the  VAX-11  FORTRAN,  which  means  2  additional  bytes 
of  core  is  used.  These  two  additional  bytes  will  not 
significantly  affect  the  total  amount  of  memory  used. 

5. 2. 1.4  FORMAT  Statement 

There  were  two  uses  of  the  FORMAT  statement  that  are 
incompatible  between  the  VAX-11  and  MODCOMP  FORTRAN  compilers. 

They  are  the  use  of  the  first  character  in  the  FORMAT  statement 
for  vertical  spacing  when  a  record  is  printed,  and  the  use  of  the 
double  quote  (") . 

The  VAX-11  FORTRAN  compiler  does  not  recognize  a  vertical 
spacing  character  unless  it  is  enclosed  in  single  quotes  ('  ’). 

For  character  transmission,  MODCOMP  allows  both  the  single  quote 
and  the  double  quotes  in  the  FORMAT  statement.  The  VAX  FORTRAN 
compiler  also  does  not  recognize  the  double  quote  as  it  is  used  in 
the  MODCOMP  FORTRAN  FORMAT  statements.  The  incompatibilities  are 
indicated  in  Table  5-5. 


Table  5-5.  FORMAT  Statement 


MODCOMP  FORTRAN 

VAX- 11  FORTRAN 

FORMAT  (0//) 

FORMAT  CO'//) 

FORMAT  ("ENTER  YES/NO") 

FORMAT  ('ENTER  YES/NO') 

FORMAT  ('ENTER  YES/NO') 

FORMAT  ('ENTER  YES/NO') 
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5. 2. 1.5  Integer  String  Statements 


There  are  several  places  in  the  MODCOMP  FORTRAN  programs 
where  the  INTEGER  type  statement  in  conjunction  with  a  DATA 
statement  is  used  to  specify  string  data.  The  VAX-11  FORTRAN 
compiler  will  not  recognize  the  MODCOMP  FORTRAN  integer  string 
constructs.  The  differences  are  illustrated  below  in  Table  5-6. 


Table  5-6.  Integer  String  Statement 


MODCOMP  FORTRAN 

VAX-11  FORTRAN 

INTEGER* 2  MSG ( 4  ) 

CHARACTER*2  MSG ( 4 ) 

DATA  MSG/ '01020304'/ 

DATA  MSG/'Ol’  ,’02' ,'03'  ,'04'/ 

5.2.2  Executable  Statements 

This  section  describes  those  executable  statements  which  are 
incompatible  that  will  require  conversion  to  the  VAX-11  FORTRAN 
constructs.  Executable  statements  describe  the  actions  of  the 
FORTRAN  program. 

5. 2. 2.1  Formatted  Direct  Access  Input/Output  Statements 

Formatted  direct  access  input/output  (I/O)  transmits 
character  data  to  and  from  files  on  a  direct  access  device.  The 
VAX-11  FORTRAN  compiler  does  not  accept  the  END  parameter  in  a 
formatted  direct  access  READ  or  WRITE  statement.  However,  the 
MODCOMP  compiler  allows  an  END  parameter.  All  formatted  READ  and 
WRITE  statements  that  have  the  END  parameter  must  be  converted  to 
the  VAX-11  FORTRAN  form  as  indicated  below  in  Table  5-7. 
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Table  5-7.  Input/Output  Statement 


MODCOMP  FORTRAN 

VAX-11  FORTRAN 

READ  (uni t 1 rec# , f rmt ,ERR=s , 

END=  s ) list 

READ  (unit ' rec# ,f rmt ,ERR=s) 

list 

s=statement  label 


5. 2. 2. 2  ENCODE/DECODE  Statement 

The  ENCODE  and  DECODE  statements  transfer  data  according  to 
format  specifiers.  Data  transfers  are  between  variables  or  arrays 
in  the  FORTRAN  program  and  translations  are  from  internal  to 
character  form  or  vice  versa.  The  ENCODE  statement  is  similar  to 
a  WRITE  statement  and  the  DECODE  statement  is  similar  to  a  READ 
statement.  The  differences  between  the  MODCOMP  compiler  and  the 
VAX-11  FORTRAN  compiler  ENCODE/DECODE  statement  are  indicated 
below  in  Table  5-8. 


Table  5-8.  ENCODE/DECDOE  Statement 


MODCOMP  FORTRAN 

VAX-11  FORTRAN 

INTEGERS  MSG  ( 4  ) 

INTEGER  LENGTH 

ENCODE(#char ,frmt, MSG, LENGTH) 

list 

CHARACTER*8  MSG 

INTEGER  LENGTH 

ENCODE (# char , f rmt ,MSG) 

list 

LENGTH=LEN (MSG) 
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As  illustrated  in  the  table  above,  MODCOMP  FORTRAN  has  an 
optional  argument  in  its  ENCODE  statement  which  allows  one  to 
determine  the  length  of  the  character  string  being  transferred. 
This  capability  is  absent  in  the  VAX-11  FORTRAN  compiler;  however, 
one  may  use  the  instrinsic  LEN  function  for  this  purpose.  The  LEN 
function  cannot  be  used  to  determine  the  length  of  an  INTEGER 
variable;  therefore,  all  strings  that  the  LEN  function  must  act 
upon  must  be  defined  as  CHARACTER  variables  as  shown  in  the  table 
above . 

The  DECODE  statement  form  is  the  same  as  the  ENCODE 
statement.  Therefore,  it  is  not  illustrated  or  discussed. 

5. 2. 2. 3  Arithmetic  IF  Statement 

The  arithmetic  IF  statement  transfers  control  to  one  of  three 
statements,  based  on  the  value  of  an  arithmetic  expression,  under 
most  compiler  dialects.  However,  the  MODCOMP  FORTRAN  compiler 
allows  one  to  exclude  one  or  more  statement  numbers,  wherein 
control  transfers  to  the  next  executable  statement.  The  VAX-11 
FORTRAN  compiler  will  not  allow  one  to  exclude  statement  numbers. 
Therefore,  all  MODCOMP  FORTRAN  code  which  has  this  variation  of 
the  arithmetic  IF  statement  must  be  converted.  Table  5-9  below 
illustrates  the  difference. 


Table  5-9.  Arithmetic  IF  Statement 


MODCOMP  FORTRAN 

VAX-11  FORTRAN 

IF  (expression)  s^,,s^ 

I=J  s  2 

IF  (expression) s^,s2fS3 
CONTINUE 

I=J 

sn  =  Statement  labels 
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5.2.3  Embedded  Assembly 

The  VAX-11  FORTRAN  compiler  does  not  allow  embedded  (in-line) 
assembly  language  code  within  a  FORTRAN  program;  however,  several 
MODCOMP  FORTRAN  programs  have  embedded  assembly  code.  The 
embedded  assembly  code  can  be  replaced  with  a  call  statement  to  a 
separate  assembly  language  subroutine  if  the  instructions  must  be 
written  in  assembly  language  code. 

5.2.4  Recursive  Coding 

A  subroutine  that  can  be  evoked  from  within  itself  and  from 
within  another  procedure  is  called  a  recursive  subroutine.  Each 
repetition  is  usually  dependent  upon  the  result  of  the  previous 
repetition,  and  data  storage  is  re-created  for  each  calling 
level.  There  is  no  indication  that  this  feature  was  used  in  any 
of  the  programs  that  were  reviewed.  However,  it  is  a  feature  of 
the  MODCOMP  FORTRAN  compiler.  The  VAX-11  FORTRAN  compiler  does 
not  have  a  recursive  capability. 


6.0  SDCS-MIL  VAX  I  SYSTEM 


6.1  SDCS  Architecture 

Figure  6-1  illustrates  the  SDCS  Architecture  to  support  one 
satellite.  All  equipments  for  the  second  telemetry  stream 
(including  the  second  set  of  up/down  converters)  have  been 

removed.  TPU#3  and  associated  equipment  have  been  left  in  as 
redundant  equipment  (as  in  the  two  satellite  configuration) . 

Major  interface  types  are  the  same  as  for  the  two  satellite 
systems,  but  quantities  have  been  reduced  as  appropriate  to 
reflect  support  of  only  one  satellite.  Table  6-1  gives  the 
computer  interface  requirements. 

The  computer  system  to  be  used  in  the  SCDS  CD/CPS  is  a  Norden 
System  MIL  VAX  I  as  described  below.  It  can  fully  replace  the 
Classic  11/75  system  used  in  the  current  SCCE,  especially  with 
only  one  satellite  being  supported.  With  respect  to  schedule,  it 
should  be  noted  that  the  MIL  VAX  II  will  be  available  in  time  for 
implementation,  and  should  be  considered.  It  has  one-third  less 
weight,  significantly  reduced  space  requirements,  costs  less  and 
will  have  40%  more  computer  power. 

Because  information  on  the  MIL  VAX  II  was  not  available  to 
CSC  at  the  start  of  this  study,  in  its  analysis  CSC  has  used  the 
MIL  VAX  I  as  the  target  computer.  However,  the  MIL  VAX  II  has  a 
superior  cost-performance  profile,  and  should  be  used  in  any  MIL 
VAX  implementation  of  the  SCCE. 

Three  chasses  are  used  to  house  the  computer  system 
electronics:  CPU  chassis,  power-I/0  chassis  and  an  expansion 
chassis.  The  CPU  chassis  contains  the  CPU  and  up  to  four 
megabytes  of  memory  (one-half  megabyte  per  card) .  Also  contained 
within  are  the  two  UNIBUS  controllers  and  the  two  CMI  disk 
interface  controllers.  One  UNIBUS  leads  to  the  power  I/O  chassis 
while  the  second  goes  to  the  expansion  chassis. 
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Table  6-1.  CD/CPS  Interfaces 


INTERFACE  POINT 

CD/CPS  INTERFACE  TYPE 

TCS  -  D/A  Converter 

16-bit  parallel  I/O 

TCS  -  TPU  #1 

16-bit  parallel  I/O 

TCS  -  TPU  #3 

16-bit  parallel  I/O 

TCS  -  SCT-TLM 

16-bit  parallel  I/O 

TCS  -  TCT 

16-bit  parallel  I/O 

TCS  -  TCG 

16-bit  parallel  I/O 

TCS  -  SIG.  MUX 

16-bit  parallel  I/O 

TCS  -  CIU  #1 

RS-232C,  9600  bps 

TCS  -  SET  UP  TPU  #1 

RS-232C,  9600  bps 

TCS  -  SET  UP  TPU  #3 

RS-232C,  9600  bps 

TCS  -  TLM  SIMULATOR 

RS-232C ,  9600  bps 

ETI  -  UP  CONVERTER  #1 

RS-232C,  9600  bps 

ETI  -  DOWN  CONVERTER  #2 

RS-232C,  9600  bps 

AFSCF  -  DATA  TRANSMISSION 

RS-232C ,  9600  bps 

DOSS  -  DATA  TRANSMISSION 

RS-232C,  9600  bps 
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6.1.1  SDCS  Computer  System  Architecture 

Figure  6-2  presents  the  mobile  SCCE  computer  system 
architecture  based  around  the  Norden  MIL  VAX  I.  Peripherals  are 
listed  in  Table  6-2. 


Table  6-2.  SCDS  CD/CPS  Peripherals 


QUANTITY 

-  -  ■ 

DESCRIPTION 

2 

Magnetic  Disk  Drives  (134  MB  each) 

1 

Magnetic  Tape  Drive  1 

2 

Printer /Plotters 

4 

Graphics/A-N  CRTs 

1 

Shared  with  DECS 


The  power  I/O  chassis  contains  the  power  supply  for  the  CPU 
chassis  as  well  as  for  its  own  use.  Additionally,  it  has  nine  I/O 
slots  which  can  hold  various  peripheral  I/O  interface  boards. 

6. 1.1.1  Interfaces 

The  power  I/O  chassis,  UNIBUS  #1,  supports  the  following 
peripheral  interfaces: 

o  DZll-M  8  channel  RS-232C  serial  interfaces  (see  below) 

o  DRll-C  parallel  interface  to  the  Telemetry  Processing 
Unit  (TPU )  #1 

o  DRll-C  parallel  interface  to  the  Telemetry  Processing 
Unit  (TPU)  #3 

o  DRll-C  parallel  interface  to  the  D/A  converter 

o  Norden  4501  printer/plotter  interface  to  the  Miltope 
TP-3000  printer 

The  DZll-M  8  channel  RS-232C  serial  interface  supports  the 
following  asychronous  lines  (all  at  9600  bps) : 

o  Modem  on  communication  line  to  APSCF 

o  Two  directly  connected  data  lines  to  A/N  graphics  CRT's 

o  Directly  connected  data  line  to  TPU#3  set  up  controller 

o  Directly  connected  data  line  to  analog  tape  controller 

o  Directly  connected  data  line  to  Telemetry  simulator  set 

up  controller 

o  One  line  is  spare 

The  expansion  chassis  contains  its  own  power  supply  for  its 
28  I/O  slots.  Attached  to  UNIBUS  #2  from  the  CPU  chassis,  the 
expansion  chassis  uses  8  slots  to  satisfy  peripheral  interface 
requirements.  The  UNIBUS  #2  is  extended  out  of  the  expansion 


6-6 


t- 


T 


chassis  to  the  AT1161  magnetic  tape  controller  which  is  built  into 
the  magnetic  tape  drive  itself.  This  UNIBUS  also  has  the 
following  telemetry  support  interfaces: 

o  DZ11-M  8  channel  serial  interface  (see  below) 

o  DRll-C  parallel  interface  to  the  signal  multiplexer 

o  DRll-C  parallel  interface  to  the  time  code  generator 

o  DRll-C  parallel  interface  to  the  SCT-TLM 

o  TP-3000  printer  interface 

o  AT1161  magnetic  tape  interface  built  into  the  magnetic 
tape  controller 

The  DZ11-M  J  channel  RS232C  serial  interface  supports  the 
following  asynchronous  lives  (all  at  9600  bps) : 

o  Interface  with  DSCSOC  LAN 

o  Two  directly  connected  data  lines  to  A/N  graphics  CRTs 

o  Directly  connected  line  to  D/C  #1  controller 

o  Directly  connected  line  to  U/C  #1  controller 

o  Directly  connected  line  to  computer  interface  unit  #1 

(CIU#1) 

o  Directly  connected  line  to  the  Telemetry  Simulator 
o  One  line  is  spare 

Assignment  of  peripheral  I/O  was  accomplished  by  considering 
the  I/O  load  and  splitting  it  across  the  two  UNIBUSs.  Since  there 
are  two  TPU  telemetry  ports,  but  with  only  one  active  at  a  given 
time,  they  are  assigned  to  the  same  UNIBUS  (#1).  The  SCT 
telemetry,  which  would  be  active  simultaneously  with  one  TPU 
telemetry  stream,  is  assigned  to  the  second  UNIBUS.  It  has  a 
lower  throughput  as  do  the  time  code  translator,  time  code 
generator,  and  control  to  the  signal  multiplexer,  which  are  also 
assigned  to  the  second  UNIBUS.  The  D/A  converter  is  assigned  to 
the  first  UNIBUS. 
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There  are  two  printer/plotter  and  four  graphic  CRTs  which  are 
all  considered  potentially  to  be  equally  utilized.  Therefore  one 
printer/plotter  and  two  graphic  CRTs  are  assigned  to  each  UNIBUS. 

The  AT1161  magnetic  tape  drive  is  assigned  to  the  second 
UNIBUS  since,  when  it  is  active,  it  presents  a  significant 
activity  level  on  the  UNIBUS.  It  is  considered  remotely  possible 
that  the  telemetry  acquisition  could  be  interfered  with 
occasionally  during  data  span  archiving.  Hence,  it  is  placed  on 
the  UNIBUS  #2  which  does  not  handle  TPU  telemetry  stream. 

I/O  loading  on  RS-232C  serial  lines  is  similarly  considered 
to  split  the  data  load.  The  heaviest  users  of  the  DZll-M  are 
considered  to  be  the  data  communications  lines  to  the  DOSS  and 
AFSCF  as  well  as  the  four  graphic  CRTs.  The  DZll-M  on  UNIBUS  #1 
is  assigned  one  data  communications  line  and  two  graphic  CRTs. 

The  remaining  data  communications  line  and  two  graphic  CRTs  are 
assigned  to  UNIBUS  #2.  Following  this,  the  data,  control  and 
status  lines  for  various  controllers  (all  of  which  are  low 
throughput  users)  are  evenly  distributed  across  the  two  DZll-Ms. 
6.2  Norden  MIL  VAX  I  Computer  System 

6.2.1  System  Description 

This  section  describes  the  Norden  MIL  VAX  I  which  will  be 
used  in  the  SDCS.  The  MIL  VAX  I  is  a  high  performance, 
multiprogrammable  system  oriented  toward  real-time,  time  sharing 
data  processing  applications.  In  general  it  is  designed  as  a 
ruggedized,  militarized  version  of  the  Digital  Equipment 
Corporation  VAX-11/780.  As  a  general  comparison,  it  is 
computationally  equivalent  and  has  only  slightly  less  I/O 
throughput  capability. 
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6.2.2  Central  Processor  Unit 


The  MIL  VAX  I  is  a  VAX-11/750  architecture  unit  with  the 
power  of  a  VAX-11/780.  The  CPU  is  designed  around  a  32-bit 
architecture  and  a  virtual  memory  system  to  ensure  the  highest 
throughput  while  preserving  its  ability  to  respond  to  interrupts 
and  changing  application  software  demands  at  any  moment. 

Addressing  with  32  bits  permits  direct  addressing  up  to  four 
billion  bytes  of  virtual  memory.  The  instruction  set  includes 
fixed  point,  floating  point,  string/byte  manipulation,  jump, 
subroutine  and  extensive  I/O  calls,  logical  bit  field,  operations 
and  software  generated  interrupt  instructions.  Sixteen  general 
purpose  32-bit  registers  can  be  used  as  index,  base,  accumulators, 
and  temporary  storage.  A  stack  mechanism  is  implemented  through 
use  of  special  stack  instructions.  An  optional  floating  point 
accelerator  is  available  to  increase  CPU  efficiency  in  dealing 
with  floating  point  numbers.  Floating  point  numbers  addressable 
by  hardware  include  single  (32  bits)  and  double  (64  bits) 
precision. 

An  address  translation  buffer  provides  a  cache  of  likely  to 
be  used  physical  addresses.  This  cache  reduces  the  amount  of 
direct  CPU  time  to  compute  such  addresses  and  improves  CPU 
efficiency  as  a  result.  To  further  improve  performance  an  8  byte 
pre-fetch  instruction  buffer  is  used.  Data  is  fetched  in  such 
manner  as  to  overlap  processing  and  to  be  ready  to  provide  data  to 
the  CPU.  Dramatic  improvement  occurs  when  additional  memory 
cycles  would  have  been  wasted  while  the  CPU  waited  for  data  not 
aligned  or  which  cross  32-bit  longword  boundaries.  An  optional 
24KB  customer  writeable  Control  Store  is  available  for  customers 
who  need  to  augment  the  speed  and  power  of  the  basic  machine  with 
customized  instructions  or  functions.  The  CPU  can  execute  1.0 
MIPS  (32-bit  instructions). 
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6.2.3  Primary  Memory 

The  MIL  VAX  I  currently  supports  up  to  four  megabytes  of 
semiconductor  real  memory.  In  the  fourth  quarter  of  1985,  it  will 
be  able  to  support  eight  megabytes  in  the  same  cabinet  through  use 
of  new  Norden  memory  boards.  The  VAX  VMS  operating  system  will 
support  only  eight  megabytes  of  real  memory  at  this  time,  upon 
expansion  of  VMS  capabilities,  Norden  will  support  16  megabytes  of 
real  memory  in  the  same  cabinet  space  used  by  four  megabytes  today. 

An  8  KB  associative  cache  memory  is  used  to  reduce  the  1.8 
microsecond  worst-case  access  to  memory  to  290  nanoseconds.  While 
slower  than  a  comparable  250  nanoseconds  for  the  MODCOMP,  the  VAX 
CPU  can  execute  slightly  more  MIPS  due  to  its  32-bit  data  busses 
for  data  transfer  and  other  aspects  of  such  an  32-bit 
architecture,  and  thereby  overcome  the  MODCOMP  memory  cycle  time 
advantage.  Memory  addresses  are  also  interleaved,  which  reduces 
waiting  time  for  memory  reference  by  the  CPU  or  I/O  device  active 
at  any  given  moment. 

An  error  checking  and  correcting  (EC C)  scheme  is  provided 
which  can  detect  all  double  bit  errors  and  detect/correct  all 
single  bit  errors.  Eight  ECC  check  bits  are  stored  with  each 
quadword  (64  bits  data  +  8  ECC  bits). 

Battery  backup  for  the  dynamic  MOS  semiconductor  memory  is 
available  as  an  option.  It  is  capable  of  supporting  four 
megabytes  for  10-15  minutes  of  power  outage. 

6.2.4  I/O  Subsystem 

The  MIL  VAX  I  has  two  major  I/O  busses  for  peripheral 
devices,  one  for  controllers  that  connect  to  the  high  performance 
computer  memory  interconnect  (CMI)  backplane,  and  the  other  for 
UNIBUSSES  (of  which  there  are  two,  maximum). 
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The  disk  subsystem  will  be  connected  to  the  CMI  which  will 
ensure  high  I/O  performance  to  accommodate  system  and  application 
software  disk  I/O.  The  slower  UNIBUSSES  will  be  used  for  all 
other  peripheral  I/O  requirements  such  as  magnetic  tape,  CRT's, 
telemetry  data  acquisition,  control,  and  status  of  uplink/downlink 
equipment,  etc. 

6. 2. 4.1  Parallel  I/O  Interface 

The  DR-11C  is  a  16  bit  parallel  interface  which  can  be  used 
to  replace  the  MODCOMP  4805-2  parallel  interface.  Table  6-3  shows 
the  signal  lines  for  data,  control  and  status. 

It  may  be  necessary  to  provide  some  interface  circuitry 
between  the  DR-11C  and  the  specific  piece  of  uplink/downlink  or 
telemetry  equipment  to  provide  voltage  level  conversion  or  to 
provide  handling  of  all  control  and  status  signals  necessary  to 
the  DR11-C  and  the  equipment  (interfaces  were  originally  designed 
for  MODCOMP  equipments) . 

6. 2. 4. 2  RS232C  Asynchonous  Line  Controller 

The  DMll-C  will  provide  eight  RS232C  asynchronous  lines  per 
controller.  Limited  modem  control  is  available  with  the  DMll-C. 
Specifications  on  the  signal  and  data  lines  conforms  to  the  El A 
RS232C  standard.  Therefore,  it  should  be  possible  to  replace  all 
MODCOMP/SCCE  RS232C  interfaces  by  use  of  the  DMll-C.  Two  such 
controllers  will  be  required  to  accommodate  all  RS232C  lines  in 
the  mobile  SCCE  for  DOSS  and  AFSCF  data  transmission,  as  well  as 
for  control/status  of  the  uplink/downlink  and  telemetry  equipment. 

Speed  of  line  operations  is  9600  bps  in  all  cases,  which  is 
well  within  the  19.2  kbps  limit  of  the  DMll-C. 

6. 2. 4. 3  Printer/Plotter  Interface 

The  printer/plotter  interface  is  a  Norden  manufactured 
controller  for  the  Miltope  TP-3000  Thermal  Printer/Plotter. 
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Table  6-3.  Parallel  I/O  Interface  Signals 


NORDEN  MIL  VAX  I  & 

DEC  VAX-11/780 

MODCOMP 

CLASSIC  11/75 

DESCRIPTION 

INOO-IN15 

IBD00-IBD1S 

16  input  data 

OUTOO-OUT15 

OBI 00-0B15 

16  output  data  bits 

REQUEST  A,  B 

EXTSIN 

External 
interrupt  line 

LDINPREG 

LDIBFN 

Load  input  strobe 

NEW  DATA  READY 

ODSTBN 

Strobe  generated 
on  output  data  ready 

NEW  DATA  READY  LO 

Strobe  generated 
when  low  output 
byte  loaded 

NEW  DATA  READY  HI 

Strobe  generated 
when  high  output 
byte  loaded 

DATA  TRANSMITTED 

See  INBMTN 

Strobe  indicating 

CPU  has  taken 
user  data 

CSRO ,  1,2,3 

Combination  status 
and  command  bits 

— 

CB10N-CB15N 

Command  bits  (6) 

— 

IST03N,  05N, 

Status  bits  (7) 

11N-15N 

(03N  indicate  device 
on) 

(05N  normally  device 
error) 

Table  6-3.  Parallel  I/O  Interface  Signals  (Cont'd) 


NORDEN  MIL  VAX  I  & 

DEC  VAX-11/780 

MODCOMP 

CLASSIC  11/75 

DESCRIPTION 

INIT 

“ 

True  whenever 

UNIBUS  is 
initialized 

— 

OCSTBN 

Output  command  ready 
strobe 

— 

ODACCN 

Device  signals 
output  data  has 
been  accepted 

See  DATA  TRANSMITTED 

INBMTN 

Signals  device  that 
input  data  buffer  is 
empty.  CPU  has 
taken  data  (level 
signal,  not  pulses) 

OBFFN 

Output  ready  for 
device 

BUSYN 

Device  busy 
status  bit 

INHBCN 

Signal  to  prevent 
loading  more  input 
data  from  device 
until  CPU  has  taken 
data 
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6.2.5  Peripheral  Storage  Devices 

6. 2. 5.1  Miltope  AT1161  Magnetic  Tape  Subsystem 

While  the  fixed  SCCE  has  one  magnetic  tape  controller  and 
three  tape  drives,  the  mobile  configuration  will  have  a  controller 
and  only  one  tape  drive.  Miltope  AT1161  will  be  used  as  the 
ruggedized,  militarized  magnetic  tape  drive.  The  controller  for 
this  magnetic  tape  drive  will  be  a  four  board  unit  manufactured  by 
Norden. 

Characteristics  of  the  9-track  IBM  compatible  magnetic  tape 
subsystem  are  75  ips  drive,  800/1600  bps,  and  NRZI  recording  mode. 

6. 2. 5. 2  Miltope  RD160  Magnetic  Disk  Subsystem 

The  disk  subsystem  will  use  two  ruggedized  Miltope  RD160  disk 
drives  and  a  Norden  manufactured  controller.  Each  disk  is  dual 
ported  and  has  its  own  controller  which  is  connected  to  the  CMI 
for  high  performance.  The  second  port  of  each  disk  is  connected 
to  the  other  disk  controller  which  provides  redundancy  and  ensures 
disk  access  in  case  of  controller  failure. 

Characteristics  of  each  disk  drive  are  134  MB  of  formatted 
disk  space,  26  msec  average  access  time,  and  a  transfer  rate  of 
1.28  MB  per  second. 

There  is  a  significant  difference  in  how  these  disks  will  be 
used  compared  to  the  MODCOMP  disks.  The  MODCOMP  configuration 
uses  one  disk  as  a  system  disk  (whereas  VAX  VMS  requires  two 
disks,  although  not  100%  dedicated) ,  one  disk  for  application 
programs  and  files  (whereas  the  two  disks  of  the  MIL  VAX  I  will 
have  to  be  used)  and  has  one  spare  disk.  The  SCDS/MIL  VAX  I  will 
have  no  spare  disk  on-line. 
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The  Miltope  disk  uses  Winchester  technology  which  means  the 
disk  platters  and  read/write  heads  are  in  one  sealed  unit.  This 
unit  is  easily  removed  by  unscrewing  four  thumb  screws  and  another 
disk  unit  placed  within.  If  a  head  crash  occurs,  a  new  Winchester 
unit  can  be  put  in  place  and  operation  resumed.  Of  course,  there 
will  be  a  loss  of  data  on  the  crashed  disc  in  most  cases. 

6. 2. 5. 3  Miltope  TP-3000  Printer/Plotter  and  Interface 

The  Miltope  module  TP-3000  Thermal  Printer/Plotter  offers 
electromechanical  design  simplicity  using  non-impact  techniques. 

It  is  a  compact  device  intended  for  use  in  military  environments. 

The  unit  features  a  solid-state,  multiple  junction  print 
head.  Since  there  are  no  moving  parts  associated  with  the  print 
head,  the  life  expectancy  of  the  head  approaches  the  service  life 
of  the  printer. 

ASCII  coded  characters  (64  standard;  128  optional)  are 
generated  in  a  10  x  7  dot  matrix  pattern  exhibiting  extremely  high 
resolution  and  definition.  The  standard  TP-3000  is  a  10  character 
per  inch  80-column  printer  which  operates  at  a  print  speed  greater 
than  750  lines  per  minute.  For  greater  density,  the  Miltope 
TP-3000  features  a  dual  format  80/132  column  capability.  By  means 
of  a  selector  switch  on  the  control  panel,  the  printout  is 
converted  from  the  normal  80-column  10  character  per  inch  format 
to  a  compressed  132-column,  17-character  per  inch  format. 

The  inherent  versatility  of  the  TP-3000  is  achieved  through 
micro-processor  control  of  the  print  head  and  paper  feed.  This 
feature  provides  the  user  with  a  variety  of  character  ftnts  as 
well  as  high  resolution  full  dot  line.  The  132  column  printer 
with  the  graphics  mode  can  output  up  to  2000  dots  per  line  under 
user  software  control. 
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Printed  copy  is  output  through  a  paper  exit  slot  at  the  front 
of  the  unit.  The  TP-3000  also  provides  for  its  own  internal  paper 
supply  storage.  The  output  paper  handlers  provide  for  continuous 
paper  takeup  and  may  be  mounted  directly  on  top  of  the  standard 
TP-3000  cabinet.  An  optional  paper  stacker  is  available. 

Printer  electronics  include  a  built-in  test  capability  to 
allow  the  printer  to  exercise  and  test  all  logic  functions 
"off-line".  All  of  the  electronics  required  for  complete 
functioning  of  the  printer  are  packaged  on  two  printed  circuit 
modules  utilizing  intergrated  circuit  and  microprocessor 
technology. 

A  disadvantage  is  that  NCR  T1351  thermal  print  paper  rather 
than  ordinary  paper  is  required.  This  limitation  may  be  of 
concern  for  the  intended  operational  environment. 


6.3  Operating  System  Comparison 

With  the  MODCOMP  Classic  11/75  and  MIL  VAX  I  computers  being 
similar  with  respect  to  computational  capability  and  I/O 
utilization,  the  operating  system  becomes  the  next  area  of 
investigation  to  compare  VAX  capability  with  the  Classic  11/75. 

How  the  operating  system  schedules  and  loads  various  tasks  at 
different  priorities,  balances  demands  for  memory,  CPU  and  I/O 
resources  can  affect  the  relative  performance  of  two  systems  after 
the  hardware  has  been  considered. 

6.3.1  Memory  Management 

VAX  VMS  uses  virtual  memory  to  support  large  numbers  of  tasks 
which  may  in  themselves  be  large.  MODCOMP' s  MAX  IV  operating 
system  also  uses  virtual  memory  to  support  tasks,  but  is  much  more 
limited  in  that  tasks  can  not  be  larger  than  128  KB  for 
instruction  space  and  128  KB  for  operand  space.  MAX  IV  uses  a  512 
byte  page  of  real  memory  and  can  assign  it  as  a  task  requires  it. 
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Thus  task  memory  grows  as  required  up  to  a  maximum  of  128  KB  each 
of  instruction  memory  and  operand  memory.  Pages  may  come  in  any 
order  from  anywhere  in  the  free  page  area  of  real  memory.  MAX  IV 
does  not  release  pages  of  real  memory  in  order  to  bring  in  new 
pages.  Once  a  page  has  been  loaded  from  a  task  image  file,  it 
remains  in  real  memory  until  the  task  terminates,  the  programmer 
codes  a  release  message  or  an  overlay  is  brought  in.  Since  the 
maximum  program  size  is  fixed,  there  is  a  burden  and  hence 
additional  cost  in  software  development  and  maintenance  to  make 
use  of  memory  management  in  a  manual  manner  via  programmed  release 
of  memory,  overlays,  etc.  Tasks  can  load  their  entire  real  memory 
at  the  start  of  execution  and  this  means  that,  for  equal  priority 
tasks,  memory  is  consumed  inefficiently  since  pages  which  will  not 
be  referred  to  again  or  will  be  used  infrequently  are  generally 
resident  until  task  termination.  The  VAX  VMS  would  have  paged  out 
such  pages  to  make  room  for  other  tasks  while  generally  allowing 
tasks  to  execute. 

The  VAX  VMS  granular  unit  of  memory  assignable  is  the  "page" 
and  is  permanently  fixed  at  512  bytes.  When  a  program  is 
initiated  or  needs  more  memory,  pages  are  assigned  in  increments. 
Such  pages  of  real  memory  are  not  contiguous  and  may  come  in  any 
order  from  anywhere  in  free  real  memory  available  for  executable 
code  and  data.  A  task  may  use  up  to  2  billion  bytes  (4  billion  if 
only  one  task  is  present)  of  virtual  memory  with  real  memory 
required  to  support  it  being  much,  much  less.  Only  the  most 
currently  loaded  pages  are  in  real  memory.  As  new  pages  of 
virtual  memory  are  referenced  and  found  not  to  be  in  real  memory 
(termed  a  "page  fault")  the  new  pages  are  brought  in  from  the 
image  file  or  if  a  previously  swapped  out  page  is  required,  it  is 
re-paged  back  in  from  the  paging  file  to  real  memory.  Should  it 
be  necessary  to  make  room  for  the  new  or  returning  page,  the 
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oldest  loaded  resident  pages  are  moved  out.  Depending  on  how  many 
user  tasks  are  present  and  how  large  real  memory  is,  the  actual 
amount  of  real  memory  assigned  to  support  a  user's  virtual  address 
space  will  vary.  This,  in  turn,  affects  performance  of  tasks. 

The  collection  of  pages  in  real  memory  assigned  to  a  task  is 
called  the  "working  set".  Working  sets  fluctuate  according  to  the 
number  of  active  tasks  and  their  characteristics. 

Tasks  under  MAX  IV  can  reference  more  than  the  maximum  128K 
operand  space  by  use  of  the  direct  extended  addressing  available. 
Programmer  control  is  required  in  contrast  to  the  VAX  VMS  where 
the  system  manages  memory  transparently. 

Unlike  MAX  IV,  VAX  VMS  can  balance  the  working  set  size 
assigned  to  each  task,  in  order  to  obtain  maximum  efficiency  of 
real  memory  (defined  as  permitting  the  maximum  number  of  tasks  to 
be  resident).  It  may  take  pages  away  from  one  task's  working  set 
and  give  to  another  which  requires  additional  real  memory  or  to 
make  room  for  yet  another  task.  MAX  IV  must  maintain  the 
currently  assigned  real  memory.  Balancing  of  working  sets  under 
VMS  is  accomplished  through  parameters  which  govern  the  minimum 
working  set  size  a  task  must  have,  the  normal  upper  limit,  and  a 
final  upper  limit  to  which  a  task  may  grow  if  there  is  ample  free 
pages  available  and  temporary  borrowing  above  its  normal  limit  can 
be  permitted.  When  another  task  must  be  activated,  VMS  will 
recall  borrowed  pages  and  if  necessary  reduce  working  sets  down 
below  the  normal  upper  limit. 

MAX  IV  does  not  reduce  the  working  sets  it  has  built  up  for 
each  task.  When  space  is  required  for  a  higher  priority  task,  a 
lower  one  is  rolled  out  if  necessary  to  obtain  memory.  This  can 
lead  to  more  page  I/O  as  program  swapping  will  increase  more  than 
with  a  VAX. 
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At  times  during  their  execution,  tasks  may  perform  I/O  or  be 
found  to  be  of  a  lower  priority  than  a  newly  arriving  or 
re-awakened  task.  Under  MAX  IV,  a  lower  priority  task(s)  in  real 
memory  will  be  entirely  swapped  out  (called  roll  out)  to  a  swap 
file.  More  than  one  lower  priority  task  may  be  swapped  in  order 
to  accumulate  sufficient  memory  for  the  new  or  re-awakened  task 
which  can  then  be  loaded.  VMS  would  attempt  to  reduce  working  set 
sizes  and  perform  other  system  chores  to  obtain  memory  and  if  then 
necessary,  will  swap  out  a  lower  priority  task.  Every  attempt  to 
avoid  swapping  is  made  before  finally  resorting  to  it.  This 
reduces  disk  I/O  substantially  compared  to  that  which  might  occur 
in  a  MAX  IV  system  with  tasks  being  completely  rolled  out  if  their 
memory  is  required. 

6.3.2  Fine  Tuning 

VAX  VMS  has  an  extensive  set  of  system  performance  parameters 
compared  to  the  MAX  IV.  These  govern  intial  parameters  for  real 
memory  use,  virtual  memory  use,  task  working  set  sizes,  time 
quanta,  and  automatic  increments  to  certain  parameters  used  when 
VMS  must  adjust  the  system  performance  dynamically.  Additionally, 
certain  parameters  can  be  operator  set  while  on-line  to  fine  tune 
the  system  as  it  operates,  in  contrast  to  setting  all  parameters 
at  system  generation  time  only.  MAX  IV  does  not  have  such  an 
extensive  set  of  parameters  and  therefore  lacks  the  ability  to 
fine  tune  the  system  as  it  functions. 

6.3.3  VMS  Security  Features 

VMS  Version  4.0  currently  being  released  has  several  useful 
security  features  not  found  in  MAX  IV.  All  relate  to  passwords. 
First,  one  may  have  the  system  present  five  random  passwords  which 
are  easily  remembered  since  they  are  "pronounceable".  The  user 
need  not  use  something  which  relates  uniquely  to  him  and  could  be 
guessed  (e.g.,  wife's  maiden  name).  The  user  chooses  one 
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of  the  five  and  it  is  "installed”.  After  pre-set  time  periods, 
the  system  will  require  passwords  be  changed  and  the  previous 
password  is  prevented  from  being  re-used  as  the  new  password.  If 
selected,  two  passwords  can  be  required,  one  from  each  of  two 
persons  before  access  to  the  system  is  permitted.  Of  course  this 
depends  on  the  two  persons  not  revealing  their  passwords  to  each 
other  mutually. 

Password  grabber  programs  are  prohibited  by  use  of  the  break 
key  before  signing  on.  A  password  grabber  program  typically 
operates  as  follows:  A  user  develops  a  program  to  simulate  the 
log-on  process.  He  executes  it  and  leaves  the  terminal  (with  the 
program  still  running  and  presenting  a  screen  typical  of  an 
available  system).  A  new  user  comes  to  the  terminal  and  signs 
on.  The  program  makes  a  copy  of  the  password  used  and  then  either 
stops  (the  new  user  just  retries  log-on  thinking  sign-on  only 
failed)  or  it  passes  the  data  to  the  operating  system  (to  finish 
log-on)  and  it  disappears.  Use  of  the  break  key  in  the  log-on 
process  will  disable  such  programs  before  they  execute  the 
password  grab. 

6.3.4  Miscellaneous  VMS  4.0  Features 

Other  features  provided  in  VMS  4.0  will  be  use  of  file  names 
up  to  39  characters  in  length,  ability  to  define  terminal  keyboard 
keys  to  be  often  used  phrases  or  commands,  use  of  multiple  windows 
by  software,  and  a  single  word  response  to  common 
control-character  key  inputs  (e.g.,  control-C  meaning  cancel, 
control-Y  meaning  interrupt  will  be  displayed  as  "CANCEL”  or 
"INTERRUPT”  in  reverse  video) .  These  features  make  the  VMS  more 
user  friendly.  DEC  VMS  4.0  publications  sould  be  referenced  for 
further  detail  on  these  and  other  new  features  which  may  be  of 
interest. 


6.4  Software 


The  software  is  described  in  detail  in  Section  5  of  this 
report.  It  is  summarized  in  Table  5-1.  The  MIL  VAX  I 
implementation  supports  only  one  active  satellite,  as  compared 
with  the  Classic  11/75  implementation.  In  the  two  satellite 
configuration,  a  substantial  number  of  software  modules  are 
duplicated  to  support  the  second  satellite.  Table  5-1  summarizes 
the  unique  software  required  to  support  a  single  satellite.  The 
impact  of  the  elimination  of  duplicated  modules  in  the  MIL  VAX  I 
system  is  a  reduction  in  the  primary  memory  used  to  implement  the 
one  satellite  configuration.  Section  6.5.1  discusses  memory 
utilization  in  greater  detail. 

6.5  Memory 

6.5.1  Primary  Memory 

Primary  memory  will  have  the  VAX/VMS  operating  system,  common 
data  area,  the  SDCS  executive  module,  and  the  telemetry/beacon 
aquisition  module  permanently  resident.  As  Table  6-4  shows,  this 
requires  725KB  of  real  memory. 

All  dynamically  loaded  tasks  added  together  would  consume 
approximately  another  1600KB.  With  four  megabytes  of  memory  it  is 
possible  to  make  some  additional  number  (up  to  all  tasks  if 
desired)  memory  resident  to  improve  response  time.  As  well,  there 
would  be  little  need  for  VAX/VMS  to  perform  paging  or  swapping  on 
these  tasks  as  1.6  MB  would  still  remain  free.  Paging  would  be 
performed  only  for  initial  loading,  and  both  paging  and  swapping 
used  to  make  real  memory  serve  more  task  memory  requirements  would 
be  unnecessary.  Overlays  would  still  be  loaded  as  called. 
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Table  6-4.  Memory  Usage  -  MIL  VAX 


MEMORY  USER 

MEMORY  (BYTES) 

1  SATELLITE 

PERMANENTLY  RESIDENT: 

OPERATING  SYSTEM 

500K 

FORTRAN  RUNTIME  Library 

30K 

COMMON 

70K 

SRE 

25K 

TELEMETRY  ACQUISITION 

70K 

BEACON  ACQUISITION 

30K 

SUBTOTAL 

725K 

TEMPORARY  RESIDENT: 

TASKS 

1 , 593K 

OVERLAYS 

1 ,  407K 

SUBTOTAL 

3 , 000K 

TOTAL  ALL  SOFTWARE 

3 , 725K 

PHYSICAL  MEMORY  AVAILABLE 

4 , 000K 

REMAINING  MEMORY  (IF  ALL  S/W  IS 
RESIDENT)  FOR  EXPANSION 

275K 

REMAINING  MEMORY  (FOR  DYNAMIC  ALLOC. 

OF  TEMP.  RES.  TASKS  AND  EXPANSION) 

1 , 682K 
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However,  there  is  sufficie' t  memory  (3275  KB)  to  hold  the 
3000  KB  of  temporarily  resident  code,  and  make  the  entire  system 
memory  resident  for  the  fastest  response  time  for  any  function. 

To  do  this,  all  overlays  would  have  to  be  converted  to  subroutines 
and  all  calls  for  overlays  converted  to  subroutine  calls.  It  may 
be  more  in  line  with  reality  to  make  only  some  additional  tasks 
and  overlays  memory  resident  and  leave  less  frequently  used 
modules  as  dynamic  loading  modules. 

This  analysis  has  not  assumed  that  any  tasks/overlays  are 
made  memory  resident  other  than  those  so  specified  for  the  MODCOMP 
system.  System  engineering  and  integration  efforts  as  well  as 
experience  with  the  converted  system  will  determine  if  it  is 
beneficial  to  convert  further  tasks  to  memory  residency. 


6.5.2  Disk  Storage 


Two  Miltope  disk  storage  units  of  134  MB  each  are  provided. 
VAX/VMS  may  utilize  two  disk  drives.  One  drive  will  primarily 
contain  system  software  and  the  second  will  contain  the  dynamic 
paging  file,  where  applicable.  Pages  will  be  temporarily  stored 
in  the  paging  file  while  removed  from  real  memory.  Application 
files  will  be  spread  across  both  disks  with  application  programs 
and  the  most  active  files  placed  on  the  system  disk. 

File  sizes  on  disk  remain  the  same  as  for  MODCOMP,  except 
that  VAX/VMS  requires  18  MB  on  the  system  disk  and  9  MB  on  both 
the  paging  disks.  VAX/VMS,  FORTRAN  and  other  software  supplied  by 
DEC,  together  with  the  paging/swapping  areas  can  consume  50-70  MB 
of  disk. 

Figure  6-3  shows  a  typical  disk  allocation. 

6.6  Performance  Estimates 
6.6.1  CPU  Utilization 

The  MIL-VAX  I  is  rated  at  1  MIPS  (million  of  instructions  per 
second)  as  a  32-bit  machine  while  the  MODCOMP  Classic  II  is  rated 
at  0.96  MIPS,  but  is  only  a  16-bit  machine.  Therefore,  it  is 
logical  to  expect  that,  although  closely  rated  in  raw  numbers  for 
MIPS,  there  is  a  substantial  difference.  The  MIL-VAX  I  might  be 
really  1.2  MIPS  or  more  relative  to  the  MODCOMP.  To  measure  the 
difference,  one  would  have  to  execute  a  benchmark  on  both  systems, 
an  opportunity  unavailable  to  CSC.  CSC  has  assumed  that  MODCOMP 
can  safely  be  represented  as  a  0.96  MIPS  machine  in  estimating  the 
performance  differences.  The  MIL  VAX  performance  has  been  used  as 
1.20  MIPS  (equivalent  16-bit  instructions) . 

Performance  estimates  were  developed  by  creating  a  model  of 
the  processing  load  and  the  processing  power  of  the  given  computer 
system  (MODCOMP,  MIL  VAX  I  and  DEC  VAX  11/780).  The  major  steps 
to  this  effort  were: 
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Figure  G-3.  Typical  Disk  Allocation  -  One  Satellite 
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a.  Analyze  representative  modules  of  TCP  and  CCP.  As  shown 
in  Appendix  I,  each  listed  module  was  examined  to 
determine  the  number  of  instructions  executed  for  normal 
paths  and  abnormal  condition  paths.  Number  of 
instructions  for  paths  are  weighted  by  the  expected 
probability  of  their  occurrence. 

b.  Each  module  was  assigned  a  frequency  of  executions  per 
second. 

c.  Number  of  instructions  was  then  multiplied  by  probability 
of  execution  and  by  the  frequency  of  execution  to  yield 
the  expected  load  presented  to  the  computer  system. 

d.  The  load  of  each  module  is  summed  to  obtain  the  total 
average  load  (or  peak  load)  depending  on  which  modules 
were  included  for  average  (or  peak)  load  cases. 

It  is  to  be  noted  that  the  process  above  consists  of 
spreading  the  computational  load  of  each  module  over  the  period 
between  executions  for  that  module.  While  this  determines  whether 
the  system  is  overloaded  or  not#  in  reality,  the  system  will 
execu' a  the  highest  priority  modules  first  and  then  allocate 
remaining  capacity  to  lower  priority  modules.  The  VMS  operating 
system  will  continue  to  dispatch  modules  as  they  arrive  for 
execution  using  up  to  100%  of  the  system  if  necessary.  But  over 
time,  the  system  will  average  a  utilization  near  that  predicted 
since  there  will  also  be  "dead  periods”  of  little  or  no  activity. 

Operating  system  overhead  is  assumed  to  be  25%  of  the 
application  modules  load.  This  figure  was  arrived  at  by  watching 
the  system  manager  console  on  a  DEC  VAX-11/780  for  a  number  of 
hours  and  sampling  the  percent  of  time  spent  in  user  mode  and  the 
system  modes  (e.g.,  kernel,  executive). 
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Since  the  MIL  VAX  I  and  DEC  VAX  11/780  are  so  closely  rated 
in  MIPS  (1.20  vs  1.27)  and  are  32-bit  machines  of  the  same  general 
architecture  using  DEC  VAX/VMS,  the  analysis  of  the  MIL  VAX  I  can 
be  applied  to  the  DEC  VAX  11/780  in  a  one  satellite  configuration. 

CSC  has  had  the  opportunity  to  examine  a  report  of  SCCE 
operator  activities  performed  over  a  long  period  of  time.  Many  of 
the  activities  requiring  the  use  of  software  modules  included  in 
the  analysis  were  performed  once  or  twice  a  day,  or  less 
frequently,  such  as  weekly,  monthly,  etc.  The  analysis  CSC  has 
performed  assumes  that  many  of  these  activities  are  being 
performed  relatively  simultaneously.  Therefore,  CSC  believes  that 
the  system  will  actually  be  less  loaded  than  presented  here.  In 
fact  it  may  be  that  for  hours,  only  telemetry/beacon  acquisition, 
processing,  archiving  and  report  generation  will  be  the  only 
events  occurring. 

CSC  has  analyzed  three  conditions:  average,  playback  and 
busy  minute,  for  both  1  and  2  satellites.  The  average  condition 
represents  normal  conditions.  The  playback  condition  places  one 
satellite  telemetry  data  stream  in  a  4  Kbps  playback  mode.  The 
busy  minute  places  all  real  time  functions  at  their  normal  rate 
and  adds  to  this  processing  load,  the  processing  of  data  span 
analysis.  These  conditions  are  defined  in  greater  detail  in 
Appendix  I,  para  2.5. 

The  results  of  CSC's  processor  utilization  analysis  are 
presented  in  Table  6-5.  For  comparative  purposes*  results  are 
shown  for  the  MODCOMP,  MIL  VAX  I  and  DEC  VAX  11/780  systems. 

A  functional  breakdown  of  average  processor  utilization 
appears  in  Table  6-6.  Although  this  breakdown  is  specifically  for 
the  MODCOMP  Classic  11/75  computer  supporting  only  one  satellite, 
it  is  representative  of  the  functional  breakdown  for  average 
processor  utilization  for  the  MIL  VAX  I  or  DEC  VAX  11/780, 
supporting  one  or  two  satellites. 
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Table  6-5.  Processor  Utilization 


COMPUTER 

PROCESSING 

1  SATELLITE 

2 

SATELLITES 

3 

Rate 

(MIPS) 

OVHD 

Avg 

m 

Bsy  Min 

Avg 

2 

PLBK 

Bsy  Min 

MODCOMP 

.96 

.25 

.25 

.48 

.33 

mt 

.72 

.66 

MILVAX  I 

1.20 

.25 

.20 

.38 

.21 

.57 

.53 

VAX  11/780 

1.27 

.25 

.19 

.36 

.25 

.38 

.54 

.50 

1 

Single  satellite  in  4  Kbps  playback  mode. 


2 

One  satellite  in  4  Kbps  playback  mode,  one  satellite  in  1  Kbps 
normal  mode. 

3 

Equivalent  16-bit  instructions. 
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Table  6-6.  Functional  Breakdown  of  Average  Processor  Utilization 
MODCOMP-Baseline  .96  MIPS-One  Satellite 


CATEGORY 


FUNCTION 

UTILIZATION 

PERCENT 

TLM  Acquisition  Process 

.056 

28 

CMD ,  Gen,  Xmt 

.018 

9 

CCP 

.053 

27 

Data  Span  Analysis 

.002 

1 

Display  Generator 

.060 

30 

Intersite  Data  Transfer 

.0002 

O.S.  Interface 

.002 

Data  Span  Report  Generator 

.006 

3 

Support  Systems 

.00001 

- 

O.S.  Overhead  (.25) 

.049 

TOTAL 

.246 

100 

6.6.2  Estimated  I/O  Utilization 

6. 6. 2.1  Channel  Utilization 

Two  UNIBUSs  are  used  in  the  SDCS-MIL  VAX  I  configuration. 
UNIBUS  #1  is  utilized  2.7%  of  the  time  and  UNIBUS  #2  is  utilized 
10.7%  of  the  time  (peak  instantaneous  loading).  Refer  to  Table 
6-7,  MIL  VAX  I  I/O  Utilization. 

Utilization  estimates  for  a  peak  period  loading  were 
developed  as  follows:  Each  device  which  is  closely  related  to  the 
telemetry  rate  is  assumed  to  operate  at  that  rate  (128  words  per 
second).  Such  devices  are  the  TPUs,  TCG  (time  code  generator), 
and  TCT  (time  code  translator) ,  etc.  Other  devices  such  as  the 
printer-plotter,  tape  drive,  and  RS-232-C  lines  are  assumed  to  be 
operating  at  100%  of  the  transfer  rate  as  would  happen  during  the 
transfer  of  records  at  any  given  moment  (of  course,  this  is  a 
burst  rate  which  does  not  continue  forever).  The  estimate  for  a 
given  UNIBUS  is  the  sum  of  these  transfer  rates.  Percentage 
utilization  is  determined  by  dividing  the  total  words  transferred 
per  second  by  750K  words  per  second,  which  is  the  maximum  per 
second  rate  that  a  UNIBUS  can  handle. 

Because  the  peak  instantaneous  utilization  is  sufficiently 
low,  the  average  utilization,  which  would  be  even  lower,  has  not 
been  calculated. 

6. 6. 2. 2  Device  Utilization 

Disk  Utilization  has  been  determined  as  follows: 

Average  accesses  per  second  for  a  single  satellite,  mostly 
from  the  TLMPRl  load  module,  are  estimated  at  3.6  accesses/sec. 
Disk  accesses  are  assumed  to  have  an  average  access  time  of  30  ms 
for  either  the  MODCOMP  or  MIL  VAX  (or  DEC  VAX)  system. 

On  the  MODCOMP  system,  all  system  files  are  on  a  separate 
system  disk  and  all  data  files  are  on  a  separate  data  disk.  The 
MIL  VAX  I  system  for  the  SDCS  has  system  files  distributed  on  both 
disks,  along  with  data  files.  Thus  on  the  MIL  VAX  system  a 


6-30 


Table  6-7.  MIL  VAX  I  I/O  Utilization  -  One  Satellite 

(Word  Size  *  16  bits) 


UNIBUS  #1  (750K  words/sec  max.) 

TPU  #1 

128  words/sec 

TPU  #3 

128  words/sec 

D/A  CONVERTER 

128  words/sec 

PRINTER/PLOTTER 

10,000  words/sec 

8  LINES  (RS232C,  9600  bps) 

9,600  words/sec 

19,984  words/sec 

Utilization  (Peak  Instantaneous) 

2.7% 

UNIBUS  #2  (750K  words/sec  max.) 

PRINTER/PLOTTER 

10,000  words/sec 

SCT-TLM 

128  words/sec 

TCT 

128  words/sec 

TCG 

128  words/sec 

SIG.  MUX. 

128  words/sec 

TAPE  DRIVE 

60,000  words/sec 

8  LINES  (RS232C ,  9600  bps) 

9,600  words/sec 

80,112  words/sec 

Utilization  (Peak  Instantaneous) 

10.7% 

system  overhead  (estimated  at  10%)  is  added  to  the  3.6 
accesses/sec  resulting  in  4  accesses/sec.  The  MIL  VAX  I  spreads 
this  activity  over  two  disks.  In  the  worst  case,  peak  activity 
will  be  on  a  single  disk. 

Thus  for  the  MODCOMP  the  utilization  is  calculated  as: 

UD  “  3.6  accesses/sec  x  30ms/access  =  .11. 

For  the  MIL  VAX  I,  disk  utilization  is  calculated 

UD  =  4.0  accesses/sec  x  30ms/access  =  .12 

For  the  MIL  VAX  I  based  SDCS  system,  operating  at  a  normal  1 
Kbps  telemetry  data  rate,  this  provides  an  large  margin  of 
performance.  In  the  playback  mode,  with  telemetry  data  at  a  4 
Kbps  rate,  this  implies  a  disk  utilization  of  .48,  providing 
adequate  margin. 

CRT  activity  is  dependent  on  interactive  scenarios.  In  a 
typical  sequence  of  command  generation,  CSC  has  estimated  the 
average  CRT  activity  level  to  be  8-10  accesses  per  minute.  This 
activity  level  is  easily  supported  by  a  single  CRT  device. 
Printer/ploter  activity  is  also  tied  to  operator  interaction.  A 
single  printer/plotter  will  support  all  of  the  SCCE  requirements 
for  a  single  satellite.  A  typical  report  run  every  1-2  hours 
takes  3  minutes.  Single  graphics  outputs  take  5  minutes  to  plot. 
Printer/plotter  utilization  is  estimated  at  30-40%,  in  support  of 
a  single  satellite.  A  second  printer/plotter  will  be  required  to 
support  two  satellites. 

6.6.3  Performance  Assessment 

This  configuration  supports  only  one  active  satellite.  Peak 
processor  utilization  is  estimated  at  38%.  I/O  channel 
instantaneous  utilization  is  estimated  at  10.7%.  Average  disk 
utilization  is  estimated  at  12%.  Under  playback  conditions,  disk 


utilization  is  48%.  Allowing  for  substantial  errors  in  CSC's 
analysis,  it  appears  that  adequate  margins  exists  in  processor 
performance  and  I/O  channel  performance.  Disk  utilization  may  be 
too  high  under  playback  conditions.  Further  analysis  and 
verification  using  the  MODCOMP  system  are  recommended. 

6.7  Hardware  Cost 

Table  6-8  presents  the  cost  of  a  MIL  VAX  I  computer  system. 
This  is  a  cost  for  an  order  placed  before  June  18,  1985,  with 
delivery  for  1988  time  frame.  Hardware  cost  is  $731,020.  With 
typical  handling  charge  and  profit  (total  14%)  added,  the  cost  to 
the  government  is  estimated  at  $833,363. 
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Table  6-8.  MIL  VAX  I  Costs 


■HRH 

Model  # 

Description  Cost 

i 

M4-3000 

MIL  VAX  I  consisting  of: 

o  Data  Path 
o  Memory  Interface 
o  Control  Store 
o  Maintenance  Control 
o  UNIBUS  Adapter 
o  Memory  Controller 
o  UNIBUS  Exerciser/Terminator 
o  Two  512KB  Semiconductor 

Array  Memory 

o  8-Channel  Serial  Multiplexer 
o  Power  Supply 
o  AC  Power  Cable 
o  DC  Power  Cable 
o  Console  Cable 

UNIBUS  Cable 

6 

M4-2900 

512KB  Semiconductor 

Array  Memory 

1 

M4-8340 

Floating  Point  Processor 

1 

M4-8370 

Diagnostic  Data  Module 

1 

M4-8360 

Second  UNIBUS 

7 

M2-DR11-C 

General  Purpose  Digital 

Interface 

1 

M2-4501 

Line  Printer  Controller 

1 

M2-6003-C 

I/O  Expansion  Unit 

1 

M2-6202 

UNIBUS  Repeater 

1 

M2-DZ11-A 

8-Channel  Serial  Multiplexer 

CMI  Disk  Controller 

VENDOR  PRICE  $533,500 
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7.0  DSCSOC  -  DEC  VAX  SYSTEM 

7.1  Configuration 

The  DSCSOC  architecture  will  be  the  same  as  that  shown  in 
Figure  4-1  which  is  the  current  SCCE  architecture  for  two 
satellites.  The  primary  change  is  to  substitute  a  Digital 
Equipment  Corporation  (DEC)  VAX  11/780  for  the  current  MODCOMP 
CLASSIC  11/75.  Computer  interface  controllers  to  TCS  and  ETI 
subsystems  are  also  changed  to  be  VAX  compatible.  Figure  7-1 
shows  the  VAX  11/780  configuration.  Table  7-1  lists  the  major 
peripheral  devices. 

7.2  DEC  VAX-11/780 
7.2.1  Central  Processor 

Two  hundred  forty-eight  basic  instructions  are  included  in 
the  VAX-11/780,  allowing  arithmetic  operations,  bit/byte  string 
manipulation,  jump,  I/O,  logical  operations,  etc.  Certain 
instruction  are  provided  to  support  higher-order  language 
constructs  such  as  loops,  etc.  Full  32-bit  arithmetic  operations 
and  32-bit  addressing  are  supported.  Data  can  be  addressed  in  any 
one  of  nine  different  methods  such  as  direct  addresses,  indexed 
etc.  The  VAX  11/780  has  a  processing  rate  of  1.06  MIPS  (32-bit 
instructions).  Instruction  execution  is  rated  at  1.27  MIPS 
(equivalent  16-bit  instructions)  compared  to  1.20  MIPS  for  the  MIL 
V7  I  and  0.96  MIPS  (16-bit  instructions)  for  the  MODCOMP  Classic 
11/75. 

A  floating  point  accelerator  to  speed  up  floating  point 
calculations  is  available  as  is  a  customer  usable  "writeable 
control  store”  for  customer  instruction.  The  latter  could  be 
employed  to  optimize  and  speed-up  instructions  which  are  often 
used  or  would  otherwise  require  several  VAX-11/780  machine 
instructions . 

An  address  translation  buffer  to  speed  up  instruction 
fetch/execution  is  also  employed,  as  described  for  the  MIL  VAX  I 
processor  in  paragraph  6.2.2. 
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Figure  7-1.  DSCSOC  VAX  11/780  Configuration 


Table  7-1.  DSCSOC  CD/CPS  Peripherals 


QUANTITY 

DESCRIPTION 

3 

Magnetic  Disk  Drives  (121  MB  each) 

3 

Magnetic  Tape  Drives 

1 

Line  Printer  (600  1pm) 

3 

Printer/Plotter 

5 

AN /CRTs 

3 

Graphic  CRTs 

3 

Programmable  Function  Keyboards 

7.2.2  Primary  Memory 

The  VAX  11/780  supports  up  to  32  MB  of  semiconductor  memory. 
For  the  DSCSOC,  four  MB  minimum  of  memory  will  be  required. 
However,  VAX-VMS  can  support  up  to  eight  megabytes.  Thus,  should 
it  be  necessary  to  increase  memory  to  improve  performance 
(especially  to  allow  more  load  modules  to  be  resident  for  faster 
response  time  and  to  reduce  paging/swapping) ,  one  can  use  up  to 
eight  MB.  An  initial  use  of  six  megabytes  may  be  beneficial  to 
decrease  labor  costs  of  optimizing  SCCE  code  conversion  to  fit  a 
lesser  memory,  such  as  the  four  MB  limit. 

The  semiconductor  memory  employs  an  error  correcting  code 
scheme  to  detect  errors  and  perform  single  bit  error  corrections. 
Using  the  cache  memory  in  conjunction  with  primary  memory,  the 
cycle  time  is  290  nanoseconds  compared  to  the  MODCOMP  cycle  time 
of  250  nanoseconds.  The  true  32-bit  architecture  of  the  VAX 
11/780  compared  to  the  16-bit  architecture  of  the  MODCOMP 
overcomes  MODCOMP' s  apparent  speed  advantage. 
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Battery  backup  for  the  MOS  semiconductor  memory  is  available 
as  an  option  and  has  been  selected  for  the  DSCSOC.  It  is  capable 
of  supporting  two  megabytes  for  15-20  minutes  of  power  outage. 

7.2.3  I/O  Subsystem 

The  VAX  11/780  uses  two  types  of  busses  for  I/O.  The  high 
speed  bus  (2.0  MB/second)  is  called  a  MASSBUS  (up  to  four 
allowed),  and  supports  high  speed  devices  such  as  magnetic  tapes. 
One  is  used  in  the  DSCSOC  to  support  the  three  tape  drives. 

Two  low  speed  (1.5  MB/second)  UNIBUSSES  will  be  used  to 
support  dual  ported  magnetic  disks  (3) ,  and  all  other  interfaces 
such  as  CRTs,  telemetry  and  earth  terminal  interfaces,  printers, 
etc. 

7. 2. 3.1  Parallel  I/O  Interface 

The  16-bit  parallel  I/O  interface  is  the  DR-llw  controller. 
It  is  generally  that  described  in  paragraph  6. 2. 4.1  for  the  MIL 
VAX  I.  Signal  leads  are  the  same.  Table  6-3  can  be  used  to 
compare  MIL  VAX  I/VAX-11/780  and  MODCOMP  signals  on  the  interface 
to  the  user's  device.  Conversion  engineering  will  probably  be 
necessary  to  interface  the  DR-11W  to  the  telemetry  subsystem 
equipment  which  originally  was  designed  to  interface  to  a  MODCOMP 
parallel  I/O  controller. 

7. 2. 3. 2  RS232C  Asynchonous  Line  Controller 

The  DZ11-DP  provides  the  required  RS232C  9600  bps 
communications  lines  required.  Minimal  conversion  engineering 
should  be  necessary  as  DEC  and  MODCOMP  both  claim  to  use  the  EIA 
RS232C  standard  which  governs  voltage  levels,  waveforms,  timing, 
etc. 
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7.2.4  Peripheral  Storage  Devices 

7. 2. 4.1  Magnetic  Disk  Drives 

Three  RA80  disk  drives  having  121  MB  formatted  capacity  will 
be  used  for  the  configuration.  These  drives  have  an  average 
access  time  of  30  ms.  and  a  peak  transfer  rate  of  about  1.2 
megabits  per  second.  Winchester  technology  is  the  basis  of 
construction.  Three  drives  can  be  mounted  in  one  cabinet. 

Each  drive  has  a  dual  port  capability  as  a  standard  feature. 
Hence  either  UNIBUS  can  be  used  to  access  a  given  drive.  This 
feature  is  employed  in  the  DSCSOC  configuration. 

Seventeen  thousand  spare  sectors  are  available  for  dynamic 
defect  reallocation.  Reliability  of  the  drive  is  further  enhanced 
by  a  170-bit  error  correction  code. 

7. 2. 4. 2  Magnetic  Tape  Drives 

Three  TEU77  magnetic  tape  drives  will  be  used  in  the  DSCSOC 
configuration  for  on-line  archival  as  well  as  disk  copy/restore 
operations,  etc.  Characteristics  of  these  tape  drives  are: 
one-half  inch  width,  IBM  compatible  recording,  800/1600  bpi,  125 
ips  and  70  second  retrieval  time.  One  controller  will  be  used  to 
control  these  three  tape  transports  (maximum  is  four  transports) . 

7.2.5  Other  I/O  Devices 
7. 2. 5.1  Printer 

An  LP11  600  lines  per  minute  band  printer  can  be  used  to 
satisfy  DSCSOC  printer  requirements.  This  printer  has  an  96  ASCII 
character  set,  132  columns  6/8  lines/inch  vertical  spacing, 
self-test  capability,  and  uses  up  to  six-part  pin  feed  continuous 
fan-folded  paper. 


7. 2. 5. 2  Alphanumeric  CRT  Devices 

VTlOO's  which  are  currently  used  in  the  SCCE,  are  considered 
to  be  used  in  the  DSCSOC. 

7. 2. 5. 3  Graphics  CRT  Devices 

Tektronix  4014-11  Graphics  CRTs  which  are  currently  used  in 
the  SCCE,  are  considered  to  be  used  in  the  DSCSOC  DEC  VAX  11/780 
system. 

7. 2. 5. 4  Versatec  C-TEX-5  Switch 

The  C-TEX-5  data  switch  is  expected  to  be  used  to  coordinate 
input  to  the  Versatec  V80  printer/plotter  from  either  a  Tektronix 
4014  graphic  CRT  or  the  computer  system.  The  interface  to  the 
UNIBUS  from  the  C-TEX-5  would  be  supplied  by  Versatec. 

7. 2. 5. 5  Printer/Plotter 

The  printer/plotter  will  be  a  Versatec  V80  unit  as  currently 
used  in  the  SCCE  configuration. 

7.3  Operating  System 

The  VAX-VMS  operating  system  as  described  in  paragraph  6.3 
and  used  on  the  MIL  VAX  I  will  be  used  on  the  VAX-11/780. 

7.4  Software 

The  software  is  described  in  detail  in  Section  5  of  this 
report,  and  is  essentially  the  same  as  that  used  on  the  SDCS  MIL 
VAX  I  system.  Refer  to  Table  5-1  for  a  summary. 

7.5  Memory 

7.5.1  Primary  Memory 

Primary  memory  will  have  the  VAX/VMS  operating  system,  common 
data  area,  the  SDCS  executive  module  and  the  telemetry/beacon 
acquisition  module  permanently  resident.  As  Table  7-2  shows,  this 
requires  915K  bytes  of  memory. 
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Table  7-2 

Memory  Usage  -  DEC  VAX  11/780 


Memory  User 

Memory 

(Bytes) 

1  Satellite 

2  Satellites 

Permanently  Resident: 

Operating  System 

500K 

500K 

FORTRAN  Runtime  Library 

30K 

30K 

Common 

70K 

140K 

SRE 

25K 

25K 

Telemetry  Acquisition 

70K 

140K 

Beacon  Acquisition 

30K 

70K 

SUBTOTAL 

725K 

915K 

Temporarily  Resident 

Tasks 

1,593k 

2 , 6  8  8K 

Overlays 

1 , 407K 

2 , 397K 

SUBTOTAL 

3 , 000K 

5,085K 

Total  All  Software 

3 ,  725K 

5 , 980K 

Physical  Memory  Available 

4 , 000K 

6,000K 

Remaining  Memory  (if  all  S/W 

resident)  For  Expansion 

275K 

2  OK 

Remaining  Memory  for  Dynamic  Alloc. 

of  Temp.  Res.  Tasks  and  Expansion 

3,275K 

5 , 085K 
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All  dynamically  loaded  tasks  and  overlays  added  together 
would  consume  another  5000K  bytes  (approximately) .  With  six 
}  megabytes  of  memory  it  is  possible  to  make  some  additional  number 

of  tasks  (up  to  all  tasks  if  desired)  memory  resident  to  increase 
response  time.  Under  this  condition,  there  would  be  no  need  for 
VAX/VMS  to  perform  paging  or  swapping  on  these  tasks.  Paging 
would  be  performed  only  for  initial  loading. 

A  lower  risk  approach  would  permanently  load  all  tasks  into 
primary  memory,  but  would  dynamically  load  overlays,  as  required. 

This  analysis  has  not  assumed  that  any  tasks/overlays  are 
made  memory  resident  other  than  those  so  specified  for  the  MODCOMP 
system.  System  engineering  and  integration  efforts  as  well  as 
experience  with  the  converted  system  will  determine  if  it  is 
beneficial  to  convert  further  tasks  to  memory  residency. 

7.5.2  Disk  Storage 

Three  RA  80  121  MB  Winchester  disk  drives  are  provided  in  the 
DEC  VAX  11/780  system.  VAX/VMS  uses  two  disk  drives  in  order  to 
function  efficiently  (primarily  by  spreading  accesses). 

Allocation  of  the  VAX/VMS  and  other  system  software,  applications 
software,  and  files  as  well  as  paging/swapping  files  will  be 
generally  as  given  in  paragraph  6.5.2  for  the  MIL  VAX  I.  Files, 
however,  will  be  increased  to  account  for  two  satellites. 

The  third  disk  is  allocated  as  spare.  However,  should 
performance  needs  in  the  future  demand  it,  the  third  disk  can  be 
used  for  files,  paging/swapping,  etc.  On  failure  of  a  disk,  the 
system  can  be  reconfigured  to  use  the  remaining  two  disks. 

Figure  7-2  shows  a  typical  disk  allocation  for  the  two 
satellite  configuration. 
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Figure  7-2.  Typical  Disk  Allocation  -  Two  Satellite 


7.6  Performance  Estimates 

7.6.1  CPU  Utilization 

The  CPU  utilization  analysis  was  performed  for  the  DEC  VAX 
11/780  exactly  as  described  in  paragraph  6.6.1  for  the  MIL  VAX  I. 
Modules  included  were  expanded  to  account  for  processing  for  a 
second  satellite.  The  reader  should  refer  again  to  that  paragraph. 

The  results  of  CSC's  processor  utilization  analysis  are 
presented  in  Table  7-3  {identical  to  Table  6-5).  The  conditions 
of  the  analysis  are  defined  in  Appendix  I ,  paragraph  2.5. 

7.6.2  Estimated  I/O  Utilization 

7. 6. 2.1  Peak  Instantaneous  Channel  Utilization 

The  MASSBUS  used  has  a  utilization  of  15.4%.  Two  UNIBUSSES 
are  used  in  the  SDCS-MIL  VAX  I  configuration.  UNIBUS  #1  has  a 
maximum  instantaneous  utilization  of  84.8%  (supporting  3  disks 
simultaneously),  and  UNIBUS  #2  has  a  maximum  instantaneous 
utilization  of  17.5%.  Refer  to  Table  7-4,  DEC  VAX  11/780  I/O 
Utilization. 

Utilization  estimates  for  a  peak  period  loading  were 
developed  as  follows:  Each  device  which  is  closely  related  to  the 
telemetry  rate  is  assumed  to  operate  at  that  rate  (128  words  per 
second).  Such  devices  are  the  TPUs,  TCG  (time  code  generator)  and 
TCT  (time  code  translator),  etc.  Other  devices  such  as  the 
printer-plotter,  tape  drive  and  RS-232-C  lines  are  assumed  to  be 
operating  at  100%  of  the  transfer  rate  as  would  happen  during  the 
transfer  of  records  at  any  given  moment  (of  course,  this  is  a 
burst  rate  which  does  not  continue  forever).  The  estimate  for  a 
given  UNIBUS  is  the  sum  of  these  transfer  rates.  Percentage 
utilization  is  determined  by  dividing  the  total  words  transferred 
per  second  by  750K  words  per  second  which  is  the  maximum  per 
second  rate  that  a  UNIBUS  can  handle. 
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Table  7-3.  Processor  Utilization 


COMPUTER 

PROCESSING 

1  SATELLITE 

2 

SATELI 

jITES 

US 

OVHD 

Avg 

■ 

Bsy  Min 

Avg 

2 

PLBK 

Bsy  Min 

MODCOMP 

.96 

.25 

.25 

.48 

.33 

.50 

.72 

.66 

MILVAX  I 

1.2 

.25 

.20 

.38 

.27 

.40 

.55 

.53 

VAX  11/780 

1.27 

.25 

.19 

.36 

.25 

.38 

.54 

.50 

1 

Single  satellite  in  4  Kbps  playback  mode. 


2 

One  satellite  in  4  Kbps  playback  mode,  one  satellite  in  1  Kbps 
normal  mode. 

3 

Equivalent  16-bit  instructions. 


Table  7-4.  DEC  VAX-11/780  Channel  Utilization 

(Word  size  =  16  bits) 


Bus/Transfer  Rate 

Device  Load 

Instantaneous 

Peak  Bus  Load 

Average  Peak 

Bus  Load 

1  Sat 

2  Sat 

MASSBUS/1000  KW/S 

Tape  Drives 

100  KW/S 

Utilization 

.10 

A 

• 

H* 

O 

<  .10 

UNIBUS  #1/750  KW/S 

3  RA80  Disks 

600  KW/S 

Printer /Plot ter 

26  KW/S 

8  RS  232C  Lines 

10  KW/S 

Total 

636  KW/S 

Utilization 

.848 

.359 

.449 

UNIBUS  #2/750  KW/S 

2  Printer/Plotters 

52  KW/S 

Line  Printer 

60  KW/S 

16  RS  232C  Lines 

19  KW/S 

Total 

131  KW/S 

Utilization 

.175 

<.175 

<.175 
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7. 6. 2. 2  Peak  Average  Channel  Utilization 

As  shown  in  Appendix  A,  2.2.3,  peak  average  channel 
utilization,  Uc,  due  to  disk  activity  (the  primary  component  of 
channel  utilization) is  given  by: 


i 

i 

I 

I 


L/T 


where 

UD  =  disk  utilization 

L  =  record  length  (KW) 

T  =  rotational  period  (sec) 

Rt  =  transfer  rate  (KW/S) 

For  a  two-satellite  situation, 

UD  =  0.6 

Rt  »  660  KW/S 

L  *  7.9  KW 

T  =16  mS, 


and  Uc  *  7.9  KW 

16  MS  x  .6  =  .449 
660  KW 
S 

In  support  of  only  one  satellite, 

UD  -  .48, 
and  Uc  =  .359 

7. 6. 2. 3  Device  Utilization 

Refer  to  paragraph  6. 6. 2. 2  for  the  rationale  of  disk 
utilization  calculations.  For  the  DSCSOC,  supporting  2 
satellites,  both  at  a  normal  1  Kbps  data  rate: 

UD  *  .12  x  2  ■  .24 
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With  one  satellite  in  a  4  Kbps  playback  mode  and  one 
satellite  at  a  normal  data  rate: 

UD  =  (.12  x  4)  +  .12  =  .60 

CRT  activity  will  be  similar  to  that  described  in  paragraph 
6.2.2,  though  doubled  due  to  the  2  satellites,  and  using  an 
additional  CRT.  No  difficulty  is  anticipated  with  CRT  capacity. 
Printer/plotter  activity  is  doubled  over  the  one  satellite  case, 
but  the  presence  of  an  additional  printer/plotter  will  keep  the 
utilization  of  each  device  in  the  30%  to  40%  range. 

7.6.3  Performance  Assessment 

This  configuration  supports  two  active  satellites.  Under 
playback  conditions,  CSC  has  estimated  the  processor  utilization 
to  be  54%  (a  very  comfortable  margin).  If,  due  to  the  potential 
uncertainty  sources  listed  in  Appendix  I,  paragraph  2.4,  CSC  has 
underestimated  the  processor  utilization,  then  it  may  be  as  high 
as  72%.  This  would  constitute  an  inadequate  margin,  and  would 
result  in  significant  degradation  of  response  time  if  significant 
enhancements  are  added.  The  maximum  instantaneous  channel  rates 
are  well  below  100%.  The  worst-case  is  on  UNIBUS  #1  where 
instantaneous  bursts  of  data  may  utilize  84.8%  of  the  bus 
capacity.  The  average  bus  utilization,  under  peak  loading 
conditions,  is  45%.  This  provides  adequate  assurance  that  bus 
loading  does  not  degrade  system  performance.  However,  disk 
utilization  under  Playback  conditions  may  be  as  high  as  60%.  The 
principal  contribution  is  from  the  TLMPRl  load  module.  If,  due  to 
the  potential  uncertainty  sources  listed  in  Appendix  I,  paragraph 
2.4,  CSC  has  underestimated  the  disk  utilization,  then  it  may  be 
as  high  as  80%.  To  reduce  disk  utilization,  the  files  for  active 
satellite  1  and  2  should  be  on  separate  disks.  This  would  reduce 
disk  utilization  to  about  50%. 

All  of  the  above  considerations  are  subject  to  the 
uncertainties  of  CSC's  analysis.  Verification  of  performance 
under  these  conditions,  using  the  MODCOMP  implementation,  is 
recommended. 
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7.7  Hardware  Cost 

Table  7-5  presents  the  costs  of  a  DEC  VAX  11/780  computer 
system.  Total  cost  is  $306,441,  using  GSA  price  schedule  and  18% 
discount  (a  typical  OEM  discount) .  Adding  in  a  software  license 
cost  of  $27,620  brings  the  total  to  $334,061.  A  typical  general 
and  administrative  overhead  plus  profit  of  14%  should  be  applied 
to  give  a  cost  to  the  government  of  $380,829. 
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Table  7-5.  DEC  VAX-11/780  Configuration  Cost 


Model  Number 

Description 

780AX-AE 

VAX-11/780  (2  MB) 

MS7890-FC 

6MB  Memory 

DZ  11-DP 

8  Line  Async.  Multiplexer 

DR  11-W 

General  Purpose  DMA  I/F 

RA  81-EA 

3  456  MB  disk  drives  plus 
cabinet 

TEU77-FB 

1600/800  Tape  Drive  and 
Controller 

TU77-MF 

1600/800  9TRK  Tape  Drives 

LA120-DA 

Console 

F  P780-AA 

Floating  Point  Accelerator 

H  7112-A 

Battery  Back-up 

LPll-EB 

600  LPM  Board  Printer 

H9652-MF 

UNIBUS  Expansion  Cabinet 

BA  11-KU 

10  1/2  Inch  Expander  Box 

DD11-DK 

Expansion  Back  Planes 
for  BAll-KU 

VENDOR  PRICE 

Software  Licenses 

SUBTOTAL 

G/A  plus  profit  (14%) 
TOTAL 

Cost 


$306,441 


27,620 


334,061 

46,768 


$380,829 
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8.0  REHOSTING  COSTS  AND  SCHEDULE 

8.1  General 

This  section  addresses  the  costs  and  schedule  to  rehost  the 
SCCE  software  on  a  MIL  VAX  I  computer  system  and  follows  with  the 
additional  costs  (software  needs  be  converted  only  once)  to  use  a 
DEC  VAX  11/780  computer  in  the  DSCSOC.  Costs  and  schedule 
estimates  are  limited  to  conversion  of  software,  procurement  of 
hardware,  set-up  of  computer  and  telemetry  simulator,  integration 
and  limited  acceptance  testing  as  well  as  documentation  (to 
include  the  additional  documentation  describing  system 
hardware/software  modifications,  etc.) 

Six  phases  are  envisioned  for  conversion: 

o  System  engineering 

o  Software  Conversion 

o  Interface/Cable  Fabrication 

o  System  integration 

o  Acceptance  testing 

o  Documentation 

8.2  Rehosting  to  MIL  VAX  I 
8.2.1  System  Engineering 

System  engineering  includes  review  of  SCCE  documentation  to 
acquire  the  necessary  basic  system  knowledge  to  produce  and  test  a 
system  which  will  meet  the  system  specifications.  Other  major 
elements  are  VMS  operating  system  parameter  value  determination, 
VMS  sysgen,  specification  of  operating  system  modifications 
required,  review  and  engineering  pertaining  to  computer  hardware 
and  software  as  well  as  equipment  rack/elevation/cabling  and 
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interface  system  engineering.  Specifications  for  semi-automatic 
software  conversion  will  be  developed.  Embedded  assembly  language 
will  be  reviewed  to  determine  if  it  can  be  replaced  by  FORTRAN 
statements  in  this  faster,  more  efficient  computer  environment. 

Approximately  25  staff  months  are  required  for  these  system 
engineering  activities. 

8.2.2  Software  Conversion 

Table  8-1  presents  a  summary  of  the  software  conversion 
effort. 

8. 2. 2.1  Application  Software 

8. 2. 2. 1.1  FORTRAN  Conversion 

SCCE  FORTRAN  modules  consist  mostly  of  FORTRAN  statements, 
but  with  a  limited  amount  of  assembly  language  statements  embedded 
to  increase  the  code  efficiency  and  speed  of  operation.  In  some 
CPCs,  INCLUDE  statements  at  the  beginning  of  these  modules  bring 
in  50-150  (on  the  average)  FORTRAN  statements  related  to  COMMON 
and  to  definitions  of  various  data  elements.  For  each  FORTRAN 
module,  all  its  FORTRAN  and  assembler  statements  must  be  converted 
as  necessary  one  by  one,  but  the  code  referenced  with  INCLUDE 
statements  need  be  converted  only  once. 

As  indicated  in  Section  5.2  of  this  report,  all  of  the 
FORTRAN  statements  in  the  Modcomp  programs  may  be  replaced  by  the 
VAX  equivalents  or  copied  over  directly.  For  the  purpose  of 
estimating  software  conversion  costs,  CSC  assumes  that  the 
following  semi-automated  method  would  be  used: 

A  conversion  program  would  be  written  to  process  FORTRAN 
program  statements  according  to  the  rules  in  section  5.2  of  this 
report.  Statements  which  the  program  encounters  as  matching  one 
of  the  rules  would  be  converted.  Those  which  partially  match 


Table  8-1.  Software  Conversion  Estimates  Modcomp  to  MIL  VAX 


SOFTWARE 

FORTRAN 

ASSEMBLER 

TOTAL 

DESCRIPTION 

LoC 

SM 

KLOC 

SM 

ma 

SM 

KLOC 

SM 

SM 

CONVERSION 

s/w 

— 

H 

— 

6.0 

APPLICATIONS 

SOFTWARE 

TCP 

57,404 

0.4 

23.0 

688 

5.13 

3.5 

26.5 

CCP 

29,415 

0.4 

11.8 

- 

- 

- 

11.8 

UTILITIES 

17,383 

7.0 

3,888 

5.13 

19.9 

26.9 

COMMON 

11,000 

E|||Sh 

2.2 

- 

- 

2.2 

COMMENTS 

115,780 

gwH 

11.6 

5,000 

.1 

0.5 

12.1 

UNEXECUTABLE 

CODE1 

11,580 

HIV 

4.6 

- 

- 

- 

4.6 

AUX.  EXEC.2 

- 

- 

26,406 

10.0 

264.1 

264.1 

TOTAL  (APPLI¬ 
CATIONS) 

242,562 

- 

60.2 

35,982 

— 

288.0 

348.2 

SYSTEM 

SOFTWARE 

■ 

MACROS 

- 

- 

- 

22,400 

10.0 

224.0 

224.0 

PROCEDURES 

- 

- 

- 

5,300 

10.0 

53.0 

53.0 

TOTAL  (SYSTEM; 

27,700 

- 

277.0 

277.0 

TOTAL 

242,562 

- 

66.2 

63,682 

- 

565.0 

631.2 

1 

Format,  Data,  Specification  Statements 


2 

May  not  be  required 
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would  be  flagged  for  manual  intervention  as  would  any  assembler 
language  statements.  All  others  would  be  copied  over  as  they 
stand.  After  the  run,  the  programmer  would  correct  the  partially 
converted  (flagged)  statements,  if  any  should  occur,  and  update 
the  software  library.  The  embedded  assembler  language  statements 
would  be  replaced  manually  by  the  FORTRAN  CALL  statements.  A 
subroutine  would  be  created  manually  with  assembler  statements 
equivalent  to  those  replaced  by  the  CALL  statement. 

Using  this  method,  the  actual  conversion  plus  compilation  of 
all  modules  (but  not  including  integration)  is  estimated  at  0.4 
staff  months  per  1000  lines  of  executable  code.  COMMON  statements 
are  estimated  at  0.2  staff  months  per  1000  lines  of  code. 

COMMENTS,  which  must  be  updated,  are  estimated  at  0.1  staff  months 
per  1000  lines  of  code.  The  estimated  conversion  effort  is  66.2 
staff  months,  including  6.0  staff  months  for  the  development  of 
the  conversion  program. 

8. 2. 2. 1.2  Assembler  Language 

Those  modules  which  are  done  entirely  in  assembler  language 
should  also  be  analyzed  in  the  system  engineering  phase  of  the 
project  to  determine  if  they  could  be  coded  in  VAX  FORTRAN  due  to 
the  speed  of  the  VAX,  it's  compiler  efficiency,  and  the  purpose  of 
the  routine.  Where  FORTRAN  can  be  used,  it  should  be.  Review  of 
documentation  on  why  these  were  originally  done  in  assembler  is 
necessary  for  that  effort. 

For  estimating  purposes,  it  is  assumed  that  all  the  assembler 
code  must  be  converted  manually.  The  nature  of  the  coding  may 
change  due  to  differences  in  the  MAX  IV  and  VMS  operating 
systems.  A  figure  of  5.13  staff  months  per  1000  lines  of  code  has 
been  used  for  the  assembler  code,  exclusive  of  comments  and 
Auxiliary  Executive  Routines  resulting  in  23.4  staff  months. 
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Comments  are  estimated  to  take  an  additional  0.5  staff  months. 

The  Auxiliary  Executive  Routines  may  not  be  required.  However, 
they  are  estimated  at  10  staff  months  per  1000  lines  of  code.  The 
total  conversion  of  the  applications  assembler  software  is 
estimated  at  288.0  staff  months. 

8. 2. 2. 2  System  Software 

The  system  software  consists  of  macros  and  procedures. 

8. 2. 2. 2.1  Macros  and  Procedures 

For  the  purpose  of  estimating  the  conversion  effort,  macros 
and  procedures  are  treated  like  complex  assembler  code.  With 
27,700  lines  of  macro  code  and  procedures,  277.0  staff  months  are 
required  for  this  part  of  the  conversion. 

8.2.3  Interface/Cable  Fabrication 

Fabrication  includes  manufacturing  of  interfaces  and  cables, 
exclusive  of  the  cost  of  the  materials.  Approximately  11  staff 
months  are  required.  Interface  manufacturing  includes  final 
detail  engineering  drawings  for  circuitry  necessary  to  interface 
the  computer  to  the  telemetry  equipment.  While  standard  16-bit 
parallel  I/O  will  be  used,  the  signal  and  control  lines  may 
require  voltage  conversion  and  control  lines  may  require  some 
changes.  RS  232-C  interfaces  should  require  little  or  no 
fabrication,  but  be  used  directly  as  supplied  by  Norden.  Cable 
fabrication  will  require  final  engineering  drawings  and 
manufacturing  of  the  cables  according  to  applicable  military 
standards. 
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8.2.4  System  Integration 

Integration  activities  include  set-up  and  test  of  computer 
hardware,  the  set  up  and  test  of  TCS  and  ETIS  interfaces,  the 
installation  and  test  of  all  software,  and  functional  end-to-end 
testing  of  the  SCCE.  The  testing  is  primarily  oriented  to  the 
verification  of  the  software  conversion  and  the  verification  that 
all  hardware  interfaces  work  properly.  Approximately  28  staff 
months  are  required  to  accomplish  system  integration. 

This  integration  and  testing  is  intended  to  demonstrate  that 
the  converted  software  has  been  successfully  integrated,  that  is, 
it  all  works  together  and  implements  nominal  functional 
requirements  that  the  hardware  interfaces  are  working 
satisfactorily,  and,  that  the  rehosted  system  satisfies  all  of  its 
functional  and  performance  specification.  The  verification  of 
SCCE  functional  and  performance  specifications  is  an  essential 
part  of  system  integration  and  subsequent  acceptance  testing. 
However,  CSC  does  not  have  sufficient  information  to  adequately 
estimate  the  cost  of  this  verification.  Consequently,  in  the 
estimates  presented  herein,  CSC  has  limited  its  estimates  to  the 
integration  and  testing  required  to  verify  the  software  and 
interface  conversion.  There  is  a  more  detailed  level  of  testing 
not  included  in  these  estimates.  The  more  detailed  testing  would 
demonstrate  the  verification  of  the  SCCE's  operation  over  its 
entire  performance  envelope,  and  would  include  all  possible 
combinations  and  sequences  of  software/hardware  events  and 
activities,  such  as: 

(a)  Verification  that  all  possible  commands  and  command 
sequences  are  generated  and  transmitted  without  error, 
under  normal  and  peak  activity  conditions. 

(b)  Verification  that  all  possible  values  of  telemetry  data 
can  be  properly  processed. 
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(c)  The  correctness  of  MBA  calculations. 

(d)  The  correctness  of  Jammer  Location  calculations. 

8.2.5  Acceptance  Testing 

Acceptance  testing  will  demonstrate  to  the  government  that 
the  software  has  been  fully  converted,  and  that  the  hardware 
interfaces  from  computer  to  telemetry  equipments  are  functioning 
properly.  Approximately  12  staff  months  are  required. 

8.2.6  Documentation 

Documentation  shall  consist  primarily  of: 

o  Additional  written  documentation  concerning  module 

changes  and  listings  to  augment  existing  SCCE  software 
documentation. 

o  Additional  drawings  and  written  documentation  to  show 
"as-built"  status  of  all  modified  or  new  interfaces  and 
cables. 

o  Acceptance  test  plan. 

o  Final  Technical  Report  which  describes  the  work 

accomplished,  changes  made  to  software/hardware,  test 
results,  and  conclusions/recommendations.  It  is  intended 
to  be  a  summary  report  rather  than  a  complete  compendium 
of  all  project  data. 

Approximately  30  staff  months  will  be  required  for 
documentation. 

8.2.7  MIL  VAX  I  Rehosting  Costs 

Table  8-2  presents  the  costs  associated  with  rehosting  on  a 
MIL  VAX  I  computer  system.  This  cost  does  not  include  equipment 
transportation  costs  nor  costs  for  installing  the  system  at  a 
government  selected  site. 


8.2.8  MIL  VAX  I  Rehosting  Schedule 

Figure  8-1  presents  a  bar  chart  of  the  schedule  for  rehosting 
on  a  MIL  VAX  I.  Total  calendar  time  required  is  24  months. 

8.3  Rehosting  to  DEC  VAX-11/780 

Once  rehosting  to  a  MIL  VAX  I  has  been  performed,  software 
conversion  to  DEC  VAX-11/780  is  not  necessary  since  the  MIL  VAX  I 
(a  DEC  type  computer)  uses  DEC  VAX/VMS  operating  system  and 
support  software.  Only  activities  unique  to  a  change  of  computer 


Table  8-2.  MIL  VAX  I  Rehosting  Costs 


System  Engineering 
Software  Conversion 

Interfaces/Cables 
(labor  only) 

System  Integration 
(partial) 

Acceptance  Testing 

Documentation* 

MIL  VAX  I  Computer 
Hardware/Software 


Staff  Months 


Costs 

($K) 

With  A.E.R 

No  A.E.R 

200 

260 

5050 

2936 

88 

88 

224 

200 

96 

86 

240 

200 

833 

833 

$6729 

$4543 

♦Individual  computer  program  component  documentation  is  included 
in  the  software  conversion  estimate. 

•♦Excluding/including  Auxiliary  Executive  Routines 


I 

I 


Calendar  Months 

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20 

System  Eng 

Acquire  .  » 

Knowledge 
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(militarized  to  commercial),  and  other  interface  and  terminal 
hardware,  and  retesting  to  ensure  full  software/hardware 
integration  are  necessary.  This  section  describes  only  those 
additional  activities  and  excludes  extensive  system  tests  and 
government  site  delivery,  installation,  and  testing. 

8.3.1  System  Engineering 

System  engineering  includes  determination  of  VAX/VMS 
operating  system  parameters  for  the  DEC  VAX-11/780  hardware 
configuration,  and  equipment  rack/elevation/cabling  and  interface 
design. 

Approximately  16  staff  months  are  required  for  these 
activities. 

8.3.2  Software  Conversion 

Little  application  software  conversion  is  required.  Minor 
tuning  may  be  required.  (A  2-satellite  configuration  duplicates 
software  from  a  1-satellite  system  with  minor  changes  in  file 
names,  array  names,  etc.)  Some  system  software  must  be  rewritten, 
e.g.,  procedures  for  a  two-satellite  operation. 

The  inclusion  of  additional  real  time  functions,  e.g., 
improved  JLE  software,  may  have  an  adverse  impact  on  average  and 
peak  utilization  of  the  processor  and  I/O  devices.  Further 
analysis  of  the  impact  of  specific  proposed  enhancements  is 
recommended.  Approximately  17  staff  months  are  required  for 
software  tuning  activities. 

8.3.3  Interface/Cable  Fabrication 

Fabrication  consists  of  manufacturing  of  interfaces  and 
cables.  Approximately  11  staff  months  are  required  for 
fabrication  activities. 


8-11 


8. 3. 3.1  Interfaces  and  Cable 


Interface  implementation  includes  final  detail  engineering 
drawings,  and  development  of  circuitry  necessary  to  interface  the 
computer  to  the  telemetry  equipment.  While  standard  16-bit 
parallel  I/O  will  be  used,  the  signal  and  control  lines  may 
require  voltage  conversion,  and  control  lines  may  require  some 
changes.  RS  232-C  interfaces  should  require  little  or  no 
modification  to  equipment  as  supplied  by  DEC  and  other  equipment 
vendors. 

8.3.4  System  Integration 

Integration  activities  include  the  set-up  and  test  of 
computer  hardware,  the  set-up  and  test  of  TCS  and  EITS  equipment, 
the  installation  and  test  of  all  software,  and  functional 
end-to-end  testing  of  the  SCCE.  The  testing  is  primarily  oriented 
toward  operational  verification  of  the  software  to  ensure  that  it 
has  been  properly  converted  for  the  DEC  VAX,  and  to  verify  that 
all  hardware  interfaces  work  properly.  Testing  does  not  include 
test  of  the  complete  SCCE  performance  envelope. 

Approximately  18  staff  months  are  required  to  accomplish 
system  integration. 

8.3.5  Acceptance  Tests 

Acceptance  testing  will  be  according  to  a  test  plan  developed 
to  demonstrate  to  the  government  that  the  software  has  been  fully 
converted,  that  the  hardware  interfaces  from  computer  to  telemetry 
equipment  are  functioning  properly  and  that  the  software/hardware 
is  ready  for  complete  performance  envelope  testing  in  the  fixed 
DSCSOC  environment.  Approximately  8  staff  months  are  allowed  for 
acceptance  tests. 
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8.3.6  Documentation 

Documentation  shall  consist  primarily  of: 

o  Additional  written  documentation  concerning  module 

changes  (if  any  are  specifically  required  for  the  DEC 
VAX)  and  listings  to  augment  existing  SCCE  software 
documentation. 

o  Additional  drawings  and  written  documentation  to  show 
"as-built"  status  of  all  modified  or  new  interfaces  and 
cables  for  the  DEC  VAX. 

o  Acceptance  test  plan. 

o  Final  Technical  Report  which  describes  the  work 

accomplished,  changes  mode  to  software/hardware,  test 
results,  and  conclusions/recommendations.  It  is  intended 
to  be  a  summary  report  rather  than  a  complete  compendium 
of  all  data. 

Approximately  22  staff  months  will  be  required  for 
documentation. 

8.3.7  DEC  VAX-11/780  Rehosting  Costs 

Table  8-3  presents  the  costs  associated  with  rehosting  on  a 
DEC  VAX-11/780  computer  system.  This  cost  does  not  include 
equipment  transportation  costs  nor  costs  for  installing  the  system 
at  a  government  selected  site. 

8.3.8  DEC  VAX-11/780  Rehosting  Schedule 

Figure  8-2  presents  a  bar  chart  of  the  schedule  for  rehosting 
on  a  DEC  VAX-11/780.  Total  calendar  time  required  is  15  months. 


Table  8-3.  DEC  VAX-11/780  Rehosting  Costs 


Activit 


Staff 

Months 

Costs  ( $K) 

System  Engineering 

16 

Software  Tuning 

17 

Interfaces/Cables  (labor  only) 

11 

System  Integration  (partial) 

18 

Acceptance  Testing 

8 

Documentation 

DEC  VAX-11/780  Computer  Hardware/Software 

22 

176 

$381 


Total 


92 


$1,117 
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Calendar  Months 

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20 

System  Eng. 

Op.  System  ■ —  - 

Parameters 

Rack  Plan  . - . 

H/w  Analysis  . - . 

S/W  Analysis 
Interfaces 

I/F  . - . 

Cabling  • - . 

Software 

Software 

Tuning  - - -  ,  - - 

Integration 

H/W  Checkout  - - •  »  - « 

S/w  Checkout  - - • 

Acceptance  Test  - - - 

Documentation 

I/F  &  Cable  Doc  -  -  ■  ■ 

Accep.Test  Plan  * - - 

Tech  Report  _ _ _ 


Figure  8-2.  DEC  VAX  11/780  Rehosting  Schedule 
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9.0  CONCLUSIONS  AND  RECOMMENDATIONS 

9.1  MIL  VAX  Based  System  in  the  SDCS 

9.1.1  Hardware 

The  functionality  of  the  SCCE  to  support  a  single  active  DSCS 
satellite  can  be  achieved  by  a  Norden  Systems  MIL  VAX  I  based 
system  with  4MB  of  primary  memory.  Additional  militarized 
equipment,  e.g.,  Miltope  disks,  etc.,  is  available  to  complete  the 
configuration. 

9.1.2  Application  Software 

The  applications  software  consists  of  243K  lines  of  FORTRAN 
and  36K  lines  of  assembler.  90%  of  the  FORTRAN  is  easily 
converted  to  the  MIL  VAX  based  system.  10%  of  the  FORTRAN  is 
related  to  computer  specifics,  e.g,  word  size,  operating  system 
interfaces,  in-line  Assembler,  compiler  unique  features,  and 
require  a  more  complex,  manual  conversion.  100%  of  the  assembler 
routines  will  require  rewriting. 

9.1.3  System  Software 

System  software  consists  of  28K  lines  of  procedures  and 
macros.  All  of  this  will  have  to  be  rewritten. 

9.1.4  Performance 

The  performance  of  the  MIL  VAX  I  is  superior  to  the  MODCOMP 
CLASSIC  11/75  computer.  Slightly  higher  processing  speed,  a  full 
32-bit  machine  and  a  more  sophisticated  operating  system  insure 
that  a  MIL  VAX  system  will  outperform  the  MODCOMP  system. 

CSC  has  estimated  the  SDCS/SCCE  performance  of  a  MIL  VAX  I 
based  system,  supporting  one  satellite,  to  be  as  shown  in  Table 
9-1. 
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Table  9-1.  MIL  VAX  System  Performance  (One  Satellite) 


COMPUTER 

PROCESSOR  UTILIZATION 

I/O  UTILIZATION 

AVG 

PLBK 

BSY  MIN 

CHANNEL** 

DISK* 

PRTR** 

MODCOMP 

.25 

.48 

.33 

N/C 

.11/. 44 

.10 

MIL  VAX  I 

.20 

.38 

.27 

.11 

.12/. 48 

.10 

N/C  *  not  computed 
*  Average/Peak 
••Average 


9.1.5  Conversion  Costs 

CSC  has  estimated  the  conversion  costs  as  shown  in  Table  9-2 


Table  9-2.  MIL  VAX  I  Conversion  Costs* 
(Fully  Loaded) 


COST  ELEMENT 

COST 

LABOR 

HARDWARE  (Single  Site) 

$3,785,000 

833,363 

TOTAL  COST 

$4,618,363 

•Excludes  Auxiliary  Executive  Routines 


9-2 


I 


9.1.6  Added  Functionality 

The  inclusion  of  some  additional  non-real  time  functions, 
e.g.,  autonomous  orbit  determination,  can  be  supported  by  the 
proposed  design  with  minimal  impact  on  system  performance. 

Adequate  primary  memory  and  disk  storage  is  available  to  support 
these  functions.  The  inclusion  of  additional  real  time  functions, 
e.g.,  anomaly  detection/correction  may  adversely  impact  average 
and  peak  utilization  of  the  processor  and  I/O  devices.  Further 
analysis  of  the  impact  of  specific  proposed  additions  is 
recommended. 

9.1.7  Potentially  Difficult  Areas 

The  potentially  difficult  aspects  of  the  rehosting  effort  are: 

a.  Assembler  language  programming,  especially 
bit-manipulation  routines. 

b.  Reprogramming  of  FORTRAN  routines  with  in-line  assembler 
(on  the  MODCOMP) . 

c.  Auxiliary  Executive  Routine  programming  (if  required). 

d.  Programming  of  system  macros. 

e.  Computer  unique  features  such  as: 
o  Operating  system  interfaces 

o  Efficiency  of  compiler  generated  code 

o  Compatibility  of  system  codes  and  addresses  with  the 
applications  software 

o  Real-time  interfaces  with  TCS  hardware 
9.2  DEC  VAX  Based  System  in  the  DSCSOC 
9.2.1  Hardware 

Assuming  that  a  MIL  VAX  SCCE  has  been  developed,  including 
the  conversion  of  all  SCCE  software,  then  a  DEC  VAX  11/780  based 
system  is  a  feasible  replacement  for  the  MODCOMP  CLASSIC  11/75 
system.  The  proposed  VAX  11/780  system  with  6MB  of  memory  would 
support  2  active  DSCS  satellites. 
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All  necessary  hardware  is  available  to  implement  the  SCCE 
functions. 

9.2.2  Application  Software 

The  applications  software#  consisting  of  243K  lines  of 
FORTRAN  and  36K  lines  of  assembler  will  be  directly  transf errable 
from  the  MIL  VAX  system,  without  conversion.  The  support  of  two 
satellites  requires  duplicate  copies  of  source  code  and  respective 
load  modules.  These  duplicates  require  disk  and  primary  memory 
space,  but  do  not  significantly  increase  the  software  complexity 
or  the  software  conversion  effort. 

9.2.3  System  Software 

System  software,  consisting  of  28K  lines  of  procedures  and 
macros  may  require  some  rewriting. 

9.2.4  Performance 

The  performance  of  the  DEC  VAX  11/780  is  superior  to  the 
MODCOMP  Classic  11/75  computer.  Slightly  higher  processing  speed, 
a  full  32-bit  machine  and  a  more  sophisticated  operating  system 
insure  that  a  VAX  11/780  system  will  outperform  the  MODCOMP  system. 

CSC  has  estimated  the  performance  of  the  DEC  VAX  11/780 
system  supporting  two  satellites  as  shown  in  Table  9-3. 

The  level  of  disk  utilization  under  peak  conditions  may  not 
provide  sufficient  performance  margins.  Potential  work-arounds 
include  software  redesign  and  the  use  of  file  management  to  spread 
the  load  over  two  disks  (reducing  peak  disk  utilization  to  less 
than  50%) ,  as  well  as  possible  hardware  related  methods. 
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Table  9-3,  DEC  VAX  11/780  System  Performance  (Two  Satellites) 


COMPUTER 

PROCESSOR  UTILIZATION 

I/O  UTILIZATION 

AVG 

PLBK 

BSY  MIN 

CHANNEL** 

DISK* 

PRTR** 

MODCOMP 

.50 

.72 

.66 

N/C 

.22/. 55 

a 

DEC  VAX  11/780 

.38 

.54 

.50 

.20 

.24/. 60 

m 

N/C  *  Not  comp  d 

•Average/Peak 

••Average 


9.2.5  Conversion  Costs 

CSC  has  estimated  the  conversion  costs  as  shown  in  Table  9-4. 


Table  9-4.  DEC  VAX  11/780  Conversion  Costs* 

(Fully  Loaded) 


COST  ELEMENT 

COST 

LABOR 

$  736,000 

HARDWARE  (Single  Site) 

380,829 

TOTAL  COST 

$1,116,829 

•Assumes  software  already  converted  for  MIL  VAX  I 
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9.2.6  Impact  of  Additional  System  Enhancements 


The  inclusion  of  additional  non-real  time  functions,  e.g., 
automonous  orbit  determination,  anomaly  detection/correction  may 
have  a  noticeable  impact  on  system  performance.  Specifically, 
these  additional  functions  may  drive  processor  utilization  above 
the  80%  range,  resulting  in  slower  responses  to  operator  initiated 
functions,  slower  terminal  response,  etc.  Critical  real  time 
functions  would  continue  to  perform  adequately. 

9.2.7  Rehosting  From  MIL  VAX  to  DEC  VAX 

Because  the  MIL  VAX  and  DEC  VAX  computers  both  use  the 
VAX/VMS  operating  system,  no  major  conversion  is  expected  in 
rehosting  the  software  from  a  MIL  VAX  I  system  to  a  DEC  VAX  11/780 
system.  However,  differences  in  hardware  between  the  MIL  VAX  and 
DEC  VAX  systems  will  require  additional  effort  in  the  real-time 
interfaces  with  the  TCS. 

9.3  Validation  of  Analysis 

In  any  analytical  effort  of  the  type  reported  on  herein, 
there  is  some  margin  for  error.  CSC  has  made  assumptions  based  on 
its  experience  and  engineering  judgment.  CSC  has  attempted  to 
assess  the  impact  of  these  assumptions  (refer  to  Appendix  I,  Table 
1-2) .  CSC  recommends  that  this  analysis  be  validated  by 
determining  the  performance  of  the  GE  MODCOMP  based  system  under 
peak  conditions.  This  process  would  concentrate  on  measuring 
processor  utilization,  I/O  channel  utilization,  disk  utilization, 
etc.,  under  a  two  satellite  load,  with  one  satellite  in  4  Kbps 
playback  condition  (or  other  peak  condition) .  Peak  activity 
levels  are  most  important  although  average  levels  are  of  interest 
too. 

This  validation  would  provide  important  insights  into  the 
potential  risks  associated  with  the  proposed  rehosting  (s)  .  CSC 
believes  that  such  validation  can  be  accomplished  by  GE  without 
excessive  cost  or  impact  on  other  SCCE  production. 
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Recommendations 


As  a  means  of  reducing  the  programmatic  risk  associated  with 
the  rehosting  of  the  SCCE,  CSC  makes  the  following  recommendations: 

a.  The  existing  MODCOMP  system  at  GE  should  be  used  as  much 
as  possible  as  a  test  bed.  It  can  be  used  to  verify 
system  performance  under  peak  loading  conditions, 
particularly  to  evalate  system  margins. 

b.  The  embedded  assembler  code  on  the  MODCOMP  should  be 
replaced  with  externally  called  routines.  This  will 
permit  the  evaluation  of  its  impact  on  performance. 

c.  Disk  activity  under  peak  loads  should  be  measured  using 
the  MODCOMP  system.  If  sufficient  margins  are  not 
present,  work-around  approaches  should  be  evaluated. 

9.5  Growth  Potential  With  Improved  Hardware 

The  analysis  reported  on  herein  by  CSC  has  examined  the 
feasibility  of  rehosting  the  SCCE  without  significant  increases  in 
the  SCCE  processing  requirements,  using  currently  available 
hardware.  It  seems  likely  that  over  the  next  several  years,  it 
will  be  desirable  to  incorporate  substantial  enhancements  into  the 
SCCE.  To  assure  sufficient  growth  capability  in  the  rehosted 
system,  larger  performance  margins  with  the  present  processing 
load  are  desirable.  This  can  be  achieved  by  incorporating  faster 
processors  and  other  higher  performance  hardware.  For  example, 
the  NORDEN  MIL  VAX  II  outperforms  the  NORDEN  MIL  VAX  I ,  at  a  lower 
price.  Obviously,  the  higher  performance  MIL  VAX  II  will  provide 
higher  performance  margins  than  those  reported  here,  and  should  be 
preferred  for  use  in  the  SDCS.  A  potential  alternative  to  the 
NORDEN  computers  are  the  VAX/VMS  compatible  computers  built  by 
Rugged  Digital  Systems,  Inc.,  which  provide  comparable  performance 
at  a  lower  price,  but  with  a  reduced  environmental  envelope. 
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The  Digital  Equipment  Corporation  makes  several  higher 
performance  VAX/VMS  compatible  machines  in  addition  to  the  VAX 
11/780  considered  here.  Among  these,  the  VAX  8600  has 
approximately  four  times  the  processor  speed  of  the  VAX  11/780, 
providing  a  large  potential  for  growth.  The  MODCOMP  Corporation’s 
Classic  32/85  is  a  32-bit  computer  with  over  twice  the  processing 
speed  of  the  16-bit  MODCOMP  Classic  11/75,  and  which  will  operate 
the  existing  software  without  conversion.  Characteristics  of 
these  computers  are  summarized  in  Table  9-5. 

CSC  recommends  that  growth  requirements  for  the  SCCE  be 
identified  more  specifically,  in  order  to  better  assess  the  need 
for  higher  performance  hardware. 
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Table  9-5.  Computer  Comparison 


FEATURE 

1  - - - - - - 

cc 

MANUFACTURER 

MODCOMP 

DEC 

MODEL 

CLASSIC  11/75 

CLASSIC  32/85 

VAX  11/780 

VAX  11/785 

ES 

WORD  SIZE 

16 

32 

32 

32 

< 

MIPS 

.96 

2.4 

1.06 

1.5 

PRIMARY  MEMORY  (MB) 

2 

2-64 

2-64 

2-64 

: 

DISK  CAPACITY  (MB) * 

67 

67 

121 

121 

DISK  AAT  (MS) 

30 

30 

30 

30 

DISK  TRANSFER  RATE  (MB/S) 

1.2 

1.2 

1.2 

1.2 

TAPE  SPEED  (IPS) 

75 

75 

125 

125 

OPERATING  SYSTEM 

MAX  IV 

MAX  IV 

VAX/VMS 

VAX/VMS 

\ 

OP.  TEMP.  RANGE  (OC) 

0-40 

0-40 

10  -  40 

10  -  40 

SHOCK  (g/MS) 

3/11 

3/11 

3/11 

3/11 

PRICE  (MINIMUM  CONFIG) 

$  50K 

$  1 50K 

$145K 

$  195K 

< 

s 

PRICE  (TYPICAL  SYSTEM) 

$115K 

$248K 

$396K 

S442K 

3 

*  LARGER  DISKS  AVAILABLE  FOR  ALL  COMPUTERS 
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Table  9-5.  Computer  Comparison 


COMPUTER 


DEC 

NORDEN 

RUGGED 

DIG.  SYS. 

‘SSIC  32/85 

VAX  11/780 

VAX  11/785 

VAX  8600 

MIL  VAX  I 

MIL  VAX  II 

R/780 

R/78  5 

32 

32 

32 

32 

32 

32 

32 

32 

2.4 

1.06 

1.5 

4.45 

1.0 

1.4 

1.06 

1.5 

2-64 

2-64 

2-64 

12  -  82 

2-4 

2-8 

2-16 

1-16 

67 

121 

121 

456 

134 

134 

456 

456 

30 

30 

30 

36 

26 

26 

36 

36 

1.2 

1.2 

1.2 

1.28 

1.28 

2.2 

2.2 

2.2 

75 

125 

125 

125 

75 

75 

MAX  IV 

VAX/VMS 

VAX/VMS 

VAX/ VMS 

VAX/VMS 

VAX/VMS 

VAX/VMS 

VAX/ VMS 

0-40 

10  -  40 

10  -  40 

10  -  40 

-54  -  55 

-54  -  40 

0-50 

0-50 

3/11 

3/11 

3/11 

3/11 

15/11 

15/11 

15/11 

15/11 

$  150K 

$  14  5K 

$  195K 

$500K 

$390K 

$500K 

$248K 

$396K 

$442K 

$806K 

$730K 

$590K 
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SOFTWARE  ANALYSIS  METHODOLOGY 
1.0  SOFTWARE  ANALYSIS 

The  primary  objective  of  the  SCCE  software  analysis  is  to 
determine  hardware  requirements  for  rehosting  the  system.  This 
primary  objective  is  composed  of  the  four  secondary  objectives 
which  follow. 

1.1  Establishing  Hardware  Processing  Requirements 

Hardware  processing  requirements  are  a  function  of  the  number 
of  executable  machine  instructions  invoked  at  peak  loading  and  the 
processing  speed  of  the  central  processor.  Therefore,  one 
objective  of  the  software  analysis  is  to  determine  the  number  of 
executable  FORTRAN  and  assembler  instructions  contained  in  the 
system. 

1.2  Input/Output  Requirements 

Input/output  performance  is  measured  by  the  utilization  of 
specific  I/O  devices,  e.g.,  disk,  tape,  CRT;  and  by  the 
utilization  of  I/O  channel  capacity.  Each  I/O  device  is 
characterized  by  an  average  access  rate.  I/O  channels  are 
characterized  by  a  maximum  data  transfer  rate.  The  software  has 
been  analyzed  to  evaluate  the  I/O  traffic. 

1.3  Establishing  Primary  Storage  Requirements 

Primary  storage  segments  have  been  established  by  using 
tabulations  of  load  module  storage  taken  from  the  Computer  Program 
Performance  Specifications. 

1.4  Establishing  Disk  Storage  Requirements 

Disk  storage  requirements  have  been  established  by  using 
files  descriptions  provided  in  Computer  Program  Performance 
Specifications. 
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2.0  APPROACH 


The  CSC  approach  to  utilization  and  sizing  includes 
categorization  of  the  SCCE  software,  analysis  methodology,  and 
modeling  techniques.  Each  of  these  components  of  the  CSC  approach 
are  detailed  in  the  following  paragraphs. 

2.1  Software  Categorization 

The  SCCE  software  is  divided  into  two  basic  categories: 
system  software  and  application  software  (Fig  I— 1 ) 

2.1.1  System  Software 

The  system  software  consists  of  machine  dependent  macros  and 
procedures.  CSC  has  assumed  that  all  system  software  must  be 
rewritten  for  a  new  computer,  and  has  further  assumed  that  the 
rewriting  effort  will  be  the  same  irrespective  of  the  host 
computer.  Therefore  the  conversion  effort  for  system  software  has 
been  based  on  a  1 ines-of-code  count. 

2.1.2  Application  Software 

The  SCCE  applications  software  consists  of  two  Computer 
Program  Configuration  Items  (CPCIs) :  Telemetry  and  Command 
Program  (TCP)  and  Communications  Configuration  Program  (CCP) . 

Also  included  in  the  applications  software  are  the  utilities  and 
common  data  variables  necessary  to  support  each  CPCI,  and 
auxiliary  executive  functions. 

The  SCCE  functions  are  divided  into: 

a.  Real  time  functions 

b.  Regularly  scheduled  functions 

c.  Support  functions 

d.  Utilities 

e.  Auxiliary  Executive  Routines 
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SYSTEM 

SOFTWARE 

MACROS 

PROCEDURES 

APPLICATIONS  SOFTWARE 

O 

REAL  TIME 

-  TELEMETRY  ACQUISITION 

-  TELEMETRY  PROCESSING 

-  COMMAND  SEQUENCE  GENERATION 

-  COMMAND  MANAGEMENT 

-  DISPLAY  PROCESSING 

-  INTERSITE  DATA  TRANSFER 

o 

REGULARLY  SCHEDULED 

-  ACTIVITY  REPORT  GENERATION 

-  SUBSYSTEM  ANALYSIS 

-  ACTIVE/RELOAD 

o 

SUPPORT/BATCH 

-  COMMUNICATIONS  CONFIGURATION  MANAGEMENT 

-  DATA  BASE  GENERATION 

-  HARDWARE  DIAGNOSIS 

o 

UTILITIES 

-  BIT  MANIPULATION 

-  COMMAND  FORMATTING 

-  DATA  BUFFERING,  PACKING,  UNPACKING 

o 

AUXILIARY  EXECUTIVE  FUNCTIONS 

-  TERMINAL  DEVICE  INTERFACE 

-  DATA  TRANSFER 

-  FILE  MANAGEMENT 

-  PRINTER  SPOOLING 

Figure  1-1.  SCCE  Software 
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Many  of  the  real  time  and  regularly  scheduled  functions  can  be 
initiated  at  any  time  by  a  request  from  the  operator. 

The  real  time  (R/T)  functions  consist  of  Telemetry 
Acquisition,  R/T  satellite  performance  evaluation  provided  by  the 
telemetry  processing,  and  MBA  Configuration  Verification 
functions,  R/T  Command  Generation  and  Transmission,  Jammer 
Detection,  and  R/T  Display  Generation.  These  functions  are 
performed  by  core-resident  and  interactive  modules  which  execute 
in  the  computer  memory  concurrently.  Among  the  R/T  functions. 
Telemetry  Acquisition  has  the  highest  priority  with  Command 
Management  the  next  highest.  R/T  Display  Generation  has  the 
lowest  priority. 

The  regularly  scheduled  functions  consist  of  Subsystem 
Analysis,  Activity  Report  Generation,  and  Archival/Reload.  These 
functions  are  all  regularly  scheduled  on  data  span  termination 
(i.e.,  approximately  every  two  hours).  They  share  the  computer 
memory  and  resources  with  the  R/T  functions.  Therefore,  since 
their  priorities  are  lower,  they  execute  when  the  R/T  functions 
are  awaiting  external  input  requests.  Among  the  regularly 
scheduled  functions.  Archival  has  the  highest  priority  and 
Activity  Report  Generation  the  lowest. 

The  software  system  executes  under  the  control  of  the  SCCE 
operators  and  controllers.  The  operating  system  and  the  auxiliary 
executive  functions  provide  executive  and  input/output  routines 
for  the  applications  software  modules.  Executive  routines  include 
task  scheduling  and  dispatching  on  a  priority  basis,  interrupt 
handling,  and  memory  and  device  allocations.  input/output 
routines  include  communications  with  the  CRTs  and  keyboards,  data 
transfers  to  and  from  the  SCCE  ground  station  hardware,  file 
management  services,  and  printed  outputs. 

2.1.3  Computer  Languages 

The  SCCE  software  is  written  in  FORTRAN,  MODCOMP  assembler, 
and  a  combination  of  both  languages  (e.g.,  "in  line  assembler"). 


A- 4 


%  ■ 


CSC  has  analyzed  software  to  determine  how  many  CPCs  and  utilities 
are  written  exclusively  in  FORTRAN,  how  many  are  written 
exclusively  in  assembler,  and  how  many  make  use  of  in-line 
assembler.  Those  CPCs  and  utilities  written  in,  or  making  use  of, 
assembler  must  be  rewritten  during  the  conversion  process.  Table 
1-1  presents  the  results  of  this  part  of  the  software  analysis. 


Table  1-1 

Application  Software  -  Lines  of  Code 
by  Functional  Category 


CATEGORY 

FORTRAN 

LINES 

ASSEMBLER 

LINES 

1.  Telemetry  Acquisition  &  Processing 

9,974 

21 

2.  Command  Generation  &  Transmission 

14,146 

548 

3.  Payload  Analysis 

29,415 

0 

4.  Data  Span  Processing 

5,607 

0 

5.  Display  Generation 

9,869 

0 

6.  Intersite  Data  Transfer 

2,656 

0 

7.  Operating  System  Interface 

3,750 

119 

8.  Data  Span  Report  Generation 

3,191 

0 

9.  Support  Systems 

8,211 

0 

Utilities 

17,383 

3,888 

TOTAL  (Executable,  without 
comments) 

104,202 

4,576 

COMMENTS  (110%  of  total) 

115,780 

5,084 

Unexecutable  (5%  of  total) 

11,578 

508 

TOTAL  (without  COMMON) 

231,560 

10,168 

COMMON 

11,023 

0 

Auxiliary  Executive  Routines 

0 

26,406 

TOTAL 

242,583 

36,574 
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2.2  Software  Analysis  Methods 

2.2.1  Software  Hierarchy 

The  application  software  consists  of  modules  called  computer 
program  components  (CPCs) ,  and  utility  routines.  The  CPCs  are 
grouped  functionally  into  executable  "load  modules".  These  load 
modules  are  the  tasks  managed  by  the  operating  system.  CSC  has 
focused  its  analysis  of  processor  performance  on  these  load 
modules,  and  their  usage  of  utility  routines.  In  addition,  the 
software  is  grouped  into  two  major  computer  Program  Configuration 
Items  (CPCIs) .  These  are  the  Telemetry  and  Command  Program  (TCP) 
and  the  Communications  Configuration  Program  (CCP) .  The  software 
hierarchy  is  illustrated  in  Figure  1-2. 

2.2.2  Processor  Utilization  Methodology 

The  analysis  of  processor  utilization  (and  I/O  device 
utilization)  depends  on  the  number  of  machine  instructions  to  be 
executed  for  each  function  and  the  frequency  of  execution  of  the 
function.  CSC  has  determined  the  number  of  machine  instructions 
per  function  (load  module)  by  a  detailed  "path"  analysis  of  source 
code  listings.  (This  process  takes  into  account  the  number  of 
iterations  through  loops.)  In  addition,  the  number  of 
(executable)  lines  of  code  were  counted  as  well  as  the  number  of 
comments. 

For  high  priority  load  modules  (e.g.,  real  time  functions) 
the  path  analysis  was  used  to  produce  the  instruction  count. 
However,  for  lower  priority  load  modules,  the  lines-of-code, 
suitably  scaled,  was  used  as  the  basis  for  instruction  count.  The 
frequency  of  invocation  of  load  modules  was  determined  by  reading 
and  interpreting  information  contained  in  appropriate  Computer 
Program  Product  Specifications. 
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Figure  1-2.  Hierarchy  of  SCCE  Application  Software 
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The  processor  loading  has  been  calculated  as  follows: 
High  priority  load  modules: 


n 

PL  =  2  Ci  (fi)  (Noli) 

i-1 


where 

PL  =  processor  loading  (instr/sec) 

fi  =  frequency  of  invocation  of  i  th  load  module 

NoIi=  number  of  high  level  language  instructions  to 
implement  load  module  "i" 

n  =  total  number  of  load  modules 

Ci  =  machine  instructions _ 

high  level  language  instructions 


mi 

Noli  =  z  Pij  (Noli j) 

j-1 

where 


mi  *  number  of  paths  through  ith  load  module 

Nolij  *  number  of  instructions  on  jth  path  through  ith  load 

module 

Pij  =  probability  of  invoking  j  th  path  through  i  th  load 
module 

Other  load  modules 


n 

PL  *  2  Ci  (fi)  (LoCi)  (Ki) 

i  «  1 
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where 


LqC^  =  Lines  of  code  to  implement  i  th  load  module. 

K.  =.  High  Level  Language  Instructions  fQr  ±  th  load  module 
Lines  of  Code 


Ki  is  based  on  the  function  of  load  module  i,  and  a 
statistical  analysis  of  load  modules  for  which  both  lines  of  code 
and  number  of  instructions  were  determined. 

Two  values  of  Ki  are  used:  a  value  of  4  is  used  for  I/O  and 
data  manipulation  intensive  routines;  a  value  of  100  has  been  used 
for  mathematical  processing  intensive  routines  (e.g.,  CCP) . 

Two  values  of  Ci  are  used:  a  value  of  4  is  used  for  FORTRAN 
instructions;  a  value  of  1.2  is  used  for  assembler  instructions. 

To  determine  processor  utilization  the  following  approach  has 
been  taken. 

UTIL  *  PL  x  ( 1+OH) 

MIPS 

where 

PL  =  Processor  Loading  (described  above)  (instr/sec) 

MIPS=  Processor  instruction  rate  (instr/sec) 

OH  =  Overhead  associated  with  operating  system  (0  OH  1) 

=  .25  in  CSC's  analysis 

2.2.3  I/O  Analysis 

I/O  analysis  has  included  I/O  channel  peak  instantaneous 
utilization,  peak  average  channel  utilization,  and  device 
utilization.  I/O  channel  utilization  has  been  calculated  by 
assuming  that  all  devices  on  the  channel  are  operating  at  maximum 
rate,  and  assuring  that  under  this  worst-case  condition  the 
channel  was  not 
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overloaded.  Peak  average  channel  utilization  takes  into  account 
the  fact  that  the  applications  software  drives  the  various  devices 
on  the  data  bus  at  a  duty  cycle  which  is  considerably  lower  than 
100%.  This,  in  turn,  reduces  total  activity  on  the  data  bus.  The 
principal  load  on  the  bus  is  the  disks.  Assuming  that  the  files 
for  two  active  satellites  are  on  a  single  disk  and  we  have  a 
device  utilization  of  U^,  then  maximum  data  transfer  will  be 
generated  when  disk  head  seeks  are  not  required,  and  a  full  track 
of  data  is  accessed  in  one  rotational  period  of  the  disk.  This 
data  is  then  transmitted  on  the  UNIBUS  at  the  disk  transfer  rate. 
The  channel  utilization,  Uc  is  given  by  the  following: 

UC  =  -i-  x  UD 

RT 

where 

Rt  ■  Disk  transfer  rate  (KW/S) 

T  «  Disk  rotational  period  (sec) 

L  *  Record  length  (Kwords) 

UQ  ■  Disk  utilization 

Device  utilization  has  been  analyzed  as  follows: 

For  disk  utilization,  CSC  has  determined  that  maximum  disk 
traffic  is  generated  by  the  real-time  programs,  primarily  in 
Sv^port  of  telemetry  acquisition  and  telemetry  processing.  Disk 
activity  has  been  calculated  in  the  following  manner: 

n  mi 

ACTIVITY  *  Z  fi  Z  (Pij)  (Nij) 

i«l  j=l 


w 
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where 


ACTIVITY  is  measured  in  accesses/sec 


fi 

3 

frequency  of  invokation 

of  ith  load  module 

Pi  j 

3 

probability  of  jth  path 

through  ith  load  module 

Nij 

* 

number  of  device  accesses  for  jth  path  through  ith 

load  module 

n 

S 

number  of  load  modules 

m 

* 

number  of  paths  through 

ith  load  module 

The  disk  activity  is  compared  with  disk  access  capacity  to 
establish  disk  utilization. 

For  CRT  and  printer/plotter  devices,  the  traffic  rate  is 
primarily  dependent  on  interactive  scenarios  in  which  operator 
actions  determine  device  usage.  CSC  has  constructed  typical 
scenarios  for  these  devices. 

2.4  Sources  of  Uncertainty 

In  conducting  this  study,  CSC  has  recognized  that  much  of  the 
information  that  forms  the  basis  for  quantitative  results  has 
uncertainties  associated  with  it.  CSC  has  used  available  SCCE 
documentation,  but  has  not  been  able  to  verify  its  interpretation 
of  these  documents.  Some  parameters  associated  with  the  various 
computers  are  proprietary,  e.g.,  the  performance  of  the  operating 
systems.  The  availability  of  this  information  has  affected  the 
models  used  by  CSC.  In  this  section,  CSC  has  attempted  to 
estimate  the  probable  impact  of  these  uncertainties. 

2.4.1  Processor  Utilization  Analysis 

The  potential  uncertainty  sources  which  impact  processor 
utilization,  and  their  estimated  impact,  appear  in  Table  1-2. 

Assuming  that  the  various  sources  of  uncertainty  are 
additive,  a  worst  case  bound  is  -.7;  +.75.  That  is,  we  can  expect 
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that  our  estimates  of  processor  utilization  are  highly  likely  to 
be  in  the  range  of  .3U  to  1.75U  where  U  is  the  calculated  value  of 
processor  utilization.  Assuming  that  the  uncertainties  are 
approximately  statistically  independent  (a  weak  assumption) ,  then 
average  error  bounds  would  be  -.7/  V” 5;  +.75/V5’  (or  -.3;  +.33). 

We  can  expect  that  our  estimates  of  processor  utilization  are 
probably  in  the  range  of  .7U  to  1.33U. 

2.4.2  I/O  Utilization  Analysis 

The  potential  uncertainty  sources  which  impact  I/O  accesses 
and  their  estimated  impact  appear  in  Table  1-3  and  Table  1-4. 

For  disk  utilization,  assuming  that  the  sources  of 
uncertainty  are  additive,  a  worst  case  bound  on  the  impact  of 
uncertainty  is  approximately  +_  0.6.  That  is,  we  can  expect  that 
our  estimates  of  disk  utilization  are  highly  likely  to  be  in  the 
range  of  .4  UQ  to  1.6  UD,  where  UD  is  the  calculated  value 
of  UQ.  Assuming  that  the  uncertainties  are  statistically 
independent,  average  error  bound  would  be  +_  ,6/V"T  (or  +  .3).  We 
can  expect  that  our  estimates  of  processor  utilization  are 
probably  in  the  range  of  .7  UQ  to  1.3  Up. 

Average  channel  utilization,  calculated  under  peak  loading 
conditions,  is  dependent  on  the  peak  utilization  of  the  channel  by 
the  disks,  which  are  the  dominant  channel  load.  Disk  utilization 
has  the  uncertainties  discussed  above.  Also,  the  size  of  the 
record  accessed  by  the  disk  is  a  random  variable.  CSC's  analyses 
have  used  an  entire  track  as  the  record  size,  defining  an  extreme 
worst-case  situtation.  In  addition,  CSC  has  assumed  that  the 
effect  of  very  short  records,  which  may  be  accessed  in  a  disk 
buffer  without  any  disk  rotation,  and  the  effect  of  long  records 
requiring  more  than  1  access  per  I/O  request,  are  negligible. 

2.4.3  Interpretation  of  Uncertainty  Sources 

Figure  1-3  shows  the  estimated  values  under  peak  (playback) 
conditions  for  the  processor  utilization  and  disk  utilization. 
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Table  1-2.  Uncertainty  Sources  Impacting  Processor  Utilization 


UNCERTAINTY  SOURCE 

NOMINAL 

RANGE 

IMPACT 

Operations  System  Overhead 

.25 

.2-. 4 

-.05;+. 15 

Ratio  of  Instructions/Lines/Code 

4 

2-10 

-.15;+. 15 

Frequency  of  Execution 

N/A 

N/A 

-.4;  +.25 

Utility  calls  for  utilities 

N/A 

N/A 

-0;  +.1 

16-bit  vs  32-bit  Instruction 
Relative  Rate 

N/A 

N/A 

-.1;  +.1 

I 

Table  1-3.  Uncertainty  Sources  Impacting  Input/Output  Utilization 
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Table  1-4.  Uncertainty  Sources  Impacting  Channel  Utilization 


UNCERTAINTY  SOURCE 

NOMINAL* 

RANGE 

IMPACT 

1 

Disk  Utilization 

IBM 

BBI 

1 

Record  Size  Per  Disk  Access 

m 

mm 

mmm 

♦Refers  to  Appendix  A,  paragraph  2.2.3 

I 
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These  values  depict  the  impact  of  the  uncertainty  sources  on 
estimated  values  of  utilization.  The  line  graphs  show  the  average 
and  one  standard  deviation  (  c )  and  two  standard  deviation  (worst 
case)  ranges.  The  processor  utilization  graphs  show  that  the 
MODCOMP  Classic  11/75  may  be  overloaded  (115%)  under  these  peak 
conditions  and  even  at  the  one  ff  point  (94%)  may  be  too  close  to 
its  full  capacity.  The  DEC  VAX  11/780  may  have  processor 
utilization  as  high  as  86%  (too  high  to  allow  enhancements  to  be 
added).  The  disk  utilization  graphs  show  that  the  DEC  VAX  11/780 
may  be  as  high  as  96%  (too  high)  ,  and  even  at  the  one  cr  point 
(78%)  may  be  too  high.  As  discussed  in  7.6.3,  a  reconfiguration 
of  the  files  can  reduce  the  average  to  about  50%,  with  a  one  or 
value  of  65%,  and  a  worst  case  value  of  80%. 

Note  that  these  ranges  of  values  are  not  associated  with 
different  operational  conditions.  They  show  the  potential  impact 
of  uncertainties  in  CSC's  methodology  and  data.  To  the  extent 
that  other,  unknown,  sources  of  uncertainty  (i.e.,  not  considered 
here)  may  exist,  these  results  could  be  substantially  different. 

2.5  Cases  Analyzed 

CSC  has  identified  three  cases  of  interest  for  performance 
analysis.  They  are: 

a.  An  average  (or  baseline)  condition  that  represents  normal 
conditions  on  the  SCCE  processor,  with  either  1  or  2 
active  satellites. 

b.  A  playback  condition  in  which  one  satellite  data  stream 
is  assumed  at  a  4Kbps  playback  rate.  In  the  2  satellite 
situation,  the  second  satellite  data  stream  is  real  time 
telemetry  at  a  1  Kbps  rate. 
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c.  A  "busy  minute"  in  which  all  the  real  time  functions 
occur  at  their  normal  rate,  data  span  analysis  and 
wrap-up  processing  coincide  (time-wise)  with  the 
real-time  functions,  and  other  functions  are  delayed 
until  the  "busy  minute"  is  completed.  The  "busy  minute" 
has  been  analyzed  for  both  1  and  2  satellites,  with  the 
respective  "busy  minutes"  for  each  of  the  2  satellites 
coinciding. 

These  cases  have  been  defined  by  the  frequency  of  execution 
assigned  to  each  load  module.  In  the  average  (or  baseline)  case, 
the  frequencies  of  execution  have  been  derived  from  analyses  of 
G.E.  prepared  documentation,  specifically  the  Computer  Program 
Performance  Specification.  The  playback  and  busy  minute 
frequencies  have  been  determined  by  appropriate  modification  to 
the  baseline  data.  Frequency  data  (actually  expressed  as  the 
associated  period)  appears  in  Table  1-4.  Also,  Table  1-4 
indicates  (X)  which  load  modules  were  analyzed  by  instructions  on 
a  path  basis. 
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Table  1-5.  Load  Module  Periods 


CATEGORY 

FUNCTION 

LOAD 

MODULE 

PATH 

ANAL 

PERIOD 

AVG 

PLYBK 

BSY  MIN 

1 

Real  Time 

BCNAC 

X 

2  sec 

0.5  sec 

2  sec 

Telemetry, 

EVREAD 

X 

10  min 

10  min 

10  min 

Acquisition 

TLMAC 

X 

2  sec 

0.5  sec 

2  sec 

&  Processing 

TLMCTl 

X 

10  min 

10  min 

10  min 

TLMPR1 

X 

1  min 

15  sec 

1  min 

2 

Command 

CMDCT1 

X 

10  min 

10  min 

10  min 

Generation, 

CMDRNl 

X 

10  min 

10  min 

10  min 

Transmission, 

CMDSEG 

X 

10  min 

10  min 

10  min 

Verification 

CMDTM1 

X 

10  min 

10  min 

10  min 

CMDVFl 

X 

10  min 

10  min 

10  min 

CMDXM1 

X 

10  min 

10  min 

10  min 

3 

Payload 

CCPFUN 

5  min 

10  min 

30  min 

Analysis 

ORBDET 

1  hr 

1  hr 

1  hr 

4 

Data  Span 

ARCHVl 

X 

1  hr 

1  hr 

1  min 

Processing 

RELOAD 

X 

24  hr 

24  hr 

24hr 

SUBAN1 

X 

1  hr 

1  hr 

1  min 

WRAPl 

X 

2  hr 

2  hr 

1  min 

5 

Display 

AFILE1 

X 

1  min 

lmin 

1  min 

Generation 

BEAC01 

X 

1  min 

1  min 

1  min 

CONFI1 

X 

30  sec 

30  sec 

30  sec 

CSTATl 

X 

15  min 

15  min 

15  min 

DCATI 

X 

2  min 

2  min 

2  min 

DFILE1 

X 

15  min 

15  min 

15  min 

DISC01 

X 

1  min 

1  min 

1  min 

DISGAl 

X 

15  sec 

15  sec 

15  sec 

DIS0A1 

X 

15  sec 

15  sec 

15  sec 

GRAPH1 

X 

30  min 

30  min 

30  min 

GRDSTI 

X 

15  min 

15  min 

15  min 

LIST1 

X 

12  min 

12  min 

12  min 

SETS1 

X 

1  min 

1  min 

1  min 

SUBDl 

X 

1  min 

1  min 

1  min 

TFILE1 

X 

2  min 

2  min 

2  min 

TDMA 

X 

1  min 

1  min 

1  min 

TPDl 

X 

1  min 

1  min 

1  min 
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Table  1-5.  Load  Module  Periods  (Cont'd) 


CATEGORY 

FUNCTION 

LOAD 

MODULE 

PATH 

ANAL 

6 

Intersite 

Data  Transfer 

DOSLNK 

IDT 

7 

Operating  Sys 
Interface 

HELP 

HWDIAG 

SRE 

X 

8 

Data  Span 

Report 

Generation 

LIMSUl 

RGCMDl 

RGGENl 

RG0P1 

RGQUAl 

RGSTA1 

RPGENl 

9 

Support 

Systems 

DSORCE 

FIG 

MIFG 

MITG 

Traing 

1 

10  min 
10  min 

24  hr 
1  hr 
6  sec 


1  hr 
1  hr 
1  hr 
1  hr 


10  min 
24  hr 
24  hr 
24  hr 
8  hr 


PLYBK  IBSY  MIN 


10  min 

10  min  10  min 

24  hr  24  hr 
1  hr 

1.5  seel  6  sec 


1  hr 
1  hr 
1  hr 
1  hr 
1  hr 
15  min 


1  hr 
1  hr 
1  hr 
1  hr 

10  min 
24  hr 
24  hr 
24  hr 
8  hr 


10  min 
24  hr 
24  hr 
24  hr 
8  hr 


GLOSSARY 


bps 

bits  per  second 

CCP 

CD/CPS 

Communication  Configuration  Program 

Control  and  Display/Computer  and  Peripheral 

Subsystem 

CIV 

CM  I 

Computer  Interface  Unit 

Computer  Memory  Interconnect 

CPC 

CPC  I 

CPU 

Computer  Program  Component 

Computer  Program  Configuration  Item 

Central  Processor  Unit 

CRT 

Cathode  Ray  Tube  (display  terminal) 

D/A 

DEC 

DOCS 

DOSS 

DSCSOC 

Digital-to-Analog 

Digital  Equipment  Corporation 

DSCS  Operations  Control  System 

DSCS  Operational  Support  System 

DSCS  Operations  Center 

ECC 

Error  Checking  and  Correcting 

IPM 

I/O 

Interim  Production  Model 

Input/Output 

JLE 

Jammer  Location  Electronics 

Kb 

KB 

Kilobit 

Kilobyte 

MB 

MBA 

MHD 

MIPS 

MIL  VAX  I 

MM  I 

MODCOMP 

MTU 

Megabyte 

Multiple  Beam  Antenna 

Moving  Head  Disk 

Million  of  Instructions  Per  Second 

A  class  of  Norden  Corporation  Militarized  computer 
Man-machine  Interface 

Modular  Computer  Systems r  Inc. 

Magnetic  Tape  Unit 

Norden 

Norden  Division  of  United  Technologies 

PSCCE 

Production  Satellite  Configuration  Control 

Element 

R/T 

RS-232C 

Real-time;  receive/transmit 

Electoronic  Industries  Association  (EIA)  standard  for 
bit  serial  communications  hardware 

A-20 


SCCE  Satellite  Configuration  Control  Element 

SCF  Satellite  Control  Facility 

SCT  Satellite  Channel  Transponder 

SDCS  Survivable  DSCS  Control  System 

SIG.MUX.  Signal  Multiplexor 

TCG  Time  Code  Generator 

TCS  Telemetry  and  Command  Subsystem 

TCP  Telemetry  and  Command  Program 

TCT  Time  Code  Translator 

TPU  Telemetry  Playback  Unit 

UNIBUS  Name  for  DEC's  I/O  bus 

VAX  Class  of  DEC  Computer 


VMS 


Name  of  operating  system  for  VAX  computers 
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